Une faille permettait à une application confinée via flatpak de s'échapper de son confinement.
On apprend au passage qu'une application flatpak qui a accès au bus DBus org.freedesktop.Flatpak peut s'échapper en exécutant flatpak-spawn --host <commande>. C'est le cas notamment de l'IDE VSCode (et de sa version sans télémétrie VSCodium), ce trou dans la raquette étant nécessaire pour accéder à un terminal non confiné depuis l'IDE, comme documenté sur le dépôt de l'empaquetage flatpak de VSCode
Arnaud Rebillot rend compte des efforts fructueux pour "debianiser" Docker-ce (sous le nom de docker.io). Le problème principal réside dans le fort couplage en go entre un projet et ses dépendances : il faut alors séparer en plusieurs paquets indépendants lorsque les dépendances peuvent être utilisées ailleurs et maintenues séparément, mais sans séparer les composants d'un même logiciel.
Il est ironique de déployer tout cet effort pour "débundler" (définitions) un outil destiné à faire tourner des applications qui le sont au plus haut point (les conteneurs).
Les conteneurs sous Linux sont un assemblage de plusieurs outils plus simples: cgroups, namespace (et chroot) à des fins d'isolation des programmes. De leur côté, les jails de BSD, les zones de solaris ou les machines virtuelles sont des objets plus simples, conçus pour l'isolation dès le début.
En conséquence, les conteneurs sont plus complexes: plus flexibles mais aussi plus fragiles (il est plus facile de se tirer une balle dans le pied).
La machinerie k8s répartit des pods (groupe de conteneurs) sur des machines formant un cluster de façon à garantir la haute disponibilité. Les pods se composent en services pour mettre en œuvre une application complète. Tous ces objets et leurs droits d'accès sont gérés par k8s. Les failles peuvent permettre à un conteneur compromis de prendre le contrôle d'un pod, d'un node (machine physique ou virtuelle qui héberge les pods) ou d'objets k8s, voire du cluster complet). Xavier Mehrenberger présente tout ça puis 2 vecteurs d'attaque : helm (gestionnaire de paquets pour k8s), dans sa version 2, avait les droits d'administration du cluster mais n'effectuait par défaut aucune authentification, et la compromission d'images docker via le respository (parfois accessible en écriture) ou la liaison entre k8s et le repository (non chiffrée par défaut !)
Le filtrage du réseau entre les conteneurs doit être pris en charge par un network plugin (il en existe plusieurs, avec des fonctionnalités différentes). Guillaume Fournier examine la possibilité d'affiner les règles en contrôlant les processus de départ et/ou d'arrivée, et pas seulement les conteneurs, comme on le ferait à l'échelle d'un système avec un pare-feu classique.
Frédéric Raynal et Damien Aumaitre remarquent que kubernetes fonctionne comme un système d'exploitation, dont les processus seraient les pods (les threads les conteneurs), où le noyai est en charge de la bonne exécution de chacun et d'une juste répartition des ressources. Les modalités d'attaque classiques (compromission de processus, élévation de privilèges...) sont tout à fait transposable à cet environnement.
Les auteurs ont aussi donné une interview à nolimitsecu fin mars.
Par défaut docker n'écoute pas sur le réseau. Mais quand l'API réseau est activée (par exemple pour un orchestrateur), par défaut il n'y pas d'authentification et les communications se font en clair (port 2375).
Si on est root dans un conteneur et que celui-ci a les capacités DAC_OVERRIDE (présente par défaut) et CAP_READ_SEARCH (absente par défaut), on peut modifier des fichiers arbitraires sur l'hôte, donc en prendre le contrôle (shocker).