whoc

Une image conteneur qui extrait le runtime conteneur sous-jacent et l'envoie à un serveur distant. Interrogez le runtime conteneur sous-jacent de votre plateforme conteneur CSP préférée !

• WhoC au Defcon 29 Cloud Village
• Azurescape - recherche propulsée par whoc, la première prise de contrôle inter-comptes de conteneurs dans le cloud public (prime de 70 000 $)

Comment ça marche ?

Comme démontré par runc CVE-2019-5736, les runtimes conteneurs Linux traditionnels s'exposent aux conteneurs qu'ils exécutent via /proc/self/exe. whoc utilise ce lien pour lire le runtime conteneur qui l'exécute.

Mode Dynamique

Il s'agit du mode par défaut de whoc qui fonctionne avec les runtimes conteneurs liés dynamiquement.

1. Le point d'entrée de l'image whoc est défini sur /proc/self/exe, et l'éditeur de liens dynamique (ld.so) de l'image est remplacé par upload_runtime.
2. Une fois l'image exécutée, le runtime conteneur se ré-exécute à l'intérieur du conteneur.
3. Étant donné que le runtime est lié dynamiquement, le noyau charge notre faux éditeur de liens dynamique (upload_runtime) dans le processus du runtime et lui passe le contrôle.
4. upload_runtime lit le binaire du runtime via /proc/self/exe et l'envoie au serveur distant configuré.

Mode Attente-Exec

Pour les runtimes conteneurs liés statiquement, whoc se présente sous une autre variante : whoc:waitforexec.

1. upload_runtime est le point d'entrée de l'image et s'exécute comme PID 1 du conteneur whoc.
2. L'utilisateur est censé exécuter une commande exec dans le conteneur whoc et invoquer un fichier pointant vers /proc/self/exe (par exemple docker exec whoc_ctr /proc/self/exe).
3. Une fois l'exec effectué, le runtime conteneur se ré-exécute à l'intérieur du conteneur.
4. upload_runtime lit le binaire du runtime via /proc/$runtime-pid/exe et l'envoie au serveur distant configuré.

Essayez Localement

Vous aurez besoin de docker et python3 installés. Clonez le dépôt :

git clone [email protected]:twistlock/whoc.git && cd whoc

Configurez un serveur de fichiers pour recevoir le runtime conteneur extrait :

mkdir -p stash && cd stash
ln -s ../util/fileserver.py fileserver 
./fileserver

Depuis un autre terminal, exécutez l'image whoc dans votre environnement conteneur de choix, par exemple Docker :

cd whoc
docker build -f Dockerfile_dynamic -t whoc:latest src  # ou ./util/build.sh
docker run --rm -it --net=host whoc:latest 127.0.0.1  # ou ./util/run_local.sh

Vérifiez que le serveur de fichiers a reçu le runtime conteneur. Si vous exécutez whoc sous Docker standard, le runtime conteneur reçu devrait être runc.

--net=host n'est utilisé que dans les tests locaux pour que le conteneur whoc puisse facilement atteindre le serveur de fichiers sur l'hôte via 127.0.0.1.

Autres Plateformes

Par défaut, whoc est compilé pour linux/amd64, mais il prend également en charge d'autres architectures CPU. Le mode attente-exec peut être compilé comme d'habitude. Pour compiler whoc en mode dynamique pour d'autres architectures CPU, vous devez renseigner l'argument de build PLATFORM_LD_PATH_ARG avec le chemin de l'éditeur de liens dynamique sur l'architecture cible.

Un exemple de script de compilation pour arm64 est disponible dans util/build_arm64.sh.

Aide

Aide pour le binaire principal de whoc, upload_runtime :

Usage: upload_runtime [options] <server_ip>

Options:
 -p, --port                 Port du serveur distant, par défaut 8080
 -e, --exec                 Mode attente-exec pour les runtimes statiques, attend qu'un exec se produise dans le conteneur
 -b, --exec-bin             En mode exec, remplace le binaire par défaut créé pour l'exec, par défaut /bin/enter
 -a, --exec-extra-argument  En mode exec, passe un argument supplémentaire au runtime pour qu'il ne se termine pas trop rapidement
 -r, --exec-readdir-proc    En mode exec, au lieu de deviner le pid du runtime (ce qui donne à whoc une seule chance de l'attraper),
                            trouve le runtime en recherchant de nouveaux processus sous '/proc'