[gull] Attaque locale root kernel Linux / risque pour les services hébergés

[Marc SCHAEFER]

Salut,

On Thu, Apr 30, 2026 at 07:46:33PM +0200, Frederic Dumas via gull wrote:
> blacklist algif_aead 

J'aurais aussi pensé à priori que cela pouvait marcher.  Sous Debian,
mon premier réflexe aurait même été de faire une diversion et de
renommer algif_aead.ko (ou similaire) en DISABLED-algif_aead.ko
(il n'y a plus de code -> il n'y a plus de risque).

Je n'ai pas testé la méthode blacklist, peut-être fonctionne-t-elle
quand même, et alors l'avantage du /bin/false est que l'erreur
devient visible dans les logs: tu sais quand quelqu'un a tenté
d'exploiter le bug, et le jour où c'est corrigé et tu as besoin du
module tu vois pourquoi il ne marche pas.

L'essentiel, quand on applique un work-around:

   1) s'assurer que le work-around n'est pas malicieux

   2) s'assurer que le work-around fonctionne (en tournant à nouveau
      le PoC simplifié, sans le payload/shell code malicieux)

> Autre question concernant un container LXC. Quelle arborescence voit
> alors un attaquant qui a réussi à obtenir le privilège root depuis
> l'intérieur du container ?

J'aurais l'impression, sans l'avoir testée, qu'un utilisateur non root
qui utilise l'exploit avec succès devient la même chose que s'il avait
eu les droits sudo dans le conteneur et avait tapé sudo -s. Ce qu'il
peut faire ensuite dépend du type de conteneur (non privilégié ou
privilégiée) et des règles MAC (app-armor p.ex.) et des namespaces mis
en place.

Toutefois, tu mentionnes Docker.  Docker (ainsi que lxc comme je
l'utilise avec un cowfs) peut partager les fichiers entre container: en
effet, si tu instancies 100 conteneurs Debian trixie, ça serait un peu
dommage que ça utilise 100 x la place disque.  Dans ce cas, du point de
vue du kernel du host, tous les fichiers /usr/bin/su de tous les
conteneurs, sauf mise à jour manuelle dans le conteneur, pointent sur le
même objet du filesystem.

L'exploit consiste à corrompre une page mémoire reflétant le début du
fichier /usr/bin/su et remplacer par un shell code. Lorsque /usr/bin/su
est exécuté, c'est cette page corrompue -- et non pas le contenu non
corrompu du fichier -- qui est utilisée. Bien entendu que comme c'est
le même fichier (inode, ou dentry, etc) partout, tu pourrais alors
attaquer n'importe quel logiciel lancé souvent dans l'ensemble
des conteneurs d'un host par ce que tu veux, et alors plutôt que
de devenir root, prendre le contrôle de ce logiciel, donc de ce
conteneur.

Dans le cas d'un hébergeur de masse qui aurait des clients différents
sur le même host (ou qui tournerait du code de tiers (*)), donc avec un
kernel partagé, tu pourrais donc non seulement devenir root dans ton
propre conteneur (ce que probablement tu peux déjà faire sauf dans des
cas particuliers), mais faire faire ce que tu veux aux conteneurs des
autres clients, ce qui est déjà un cran au-dessus.

> Il se retrouve instantanément dans le répertoire /root de l'hôte ?

Non.  Ce bug ne touche pas les règles MAC (p.ex. app-armor) ni les
namespaces (réseau, fs, processus, etc).  Par défaut, le root de
lxc ou de Docker n'est pas exactement le même root que celui du host,
en particulier (dans le cas de conteneurs non privilégiés et sauf
bug de configuration).

Par contre, comme tu peux attaquer d'autres conteneurs du même host,
si tout à coup un de ces conteneurs était privilégié, tu peux bien
entendu devenir root sur le host.

Manque de pot, si tu tournes Kubernetes, il y a apparemment toujours
un conteneur qui est privilégié [1]. Donc, suivant ta configuration
ou si tout à coup tu utilises Kubernetes et qu'un seul des conteneurs
tourne du code de tiers, l'attaquant pourrait attaquer ce conteneur,
donc attaquer tous les conteneurs en cowfs sur le même host, donc
attaquer ce conteneur privilégié, et avec les privilèges supplémentaires,
"entrer" dans le host.

Cela montre aussi que les attaques d'aujourd'hui sont très souvent
multiformes, parfois complexes, parfois moins et que la notion
d'isolation (ou même d'abstraction informatique) devient très
relative.

Bon 1er mai :)

(*) définition code de tiers: c'est un peu vague, mais imagine du
    Gitlab CI/CD avec des développeurs qui ne sont pas censés accéder
    en root au conteneur qui exécute le CI/CD, ou des images Docker
    piratées, ou une installation npm avec des packages vérolés,
    ou des vrais clients externes, etc.

[1] https://www.reddit.com/r/kubernetes/comments/1szwbbo/copy_fail_cve202631431_kubernetes_container/