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

[Félix Hauri]

Le Fri, May 01, 2026 at 08:09:33AM +0200, Marc SCHAEFER via gull a écrit :
> 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).
Relativement équivalent. Un peu plus ``bourrin'', mais tant qu'à faire:
pourquoi renommer un fichier qui ne te servira à rien sinon à compromettre
ta machine. Pour moi la méthode ``bourrin'', serait:
  # find /lib/modules/ -type f -name algif_aead.ko -delete

Mais je préfère la méthode recommandée, plus system-friendly...

Mon ``òneliner'' que je colle partout:

  # echo 'install algif_aead /bin/false' >/etc/modprobe.d/disable-algif-aead.conf && echo done. && rmmod algif_aead

Si je peux lire:

  done.
  rmmod: ERROR: Module algif_aead is not currently loaded

c'est que
 - c'est fait
 - le module n'a pas été chargé avant mon passage.

Si je ne lis que la ligne ``done.'' alors
 -  # echo 3 > /proc/sys/vm/drop_caches
 - s'assurer qu'on est bien seul sur la machine: ``w'', ``who'', ``last''
 - scan en profondeur de la machine,
 - reboot
 - analyse des logs

> > 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 ?
Le ``défaut'' que j'ai relevé est que l'exploit ne change pas le GID.
Donc si tu trouve des entrées (fichier, dossier ou autre) dont l'UID
du propriétaire est 0 et le GID propriétaire correspond au GUID d'un
utlisateur particulier, alors l'entrée est suspecte! (Et tu connais le
GUID de l'attaquant.)

... Sauf si l'exploit n'est pas celui que j'ai testé. Il doit être
possible de concevoir un shellcode plus abouti, mais comme la plupart
des pirates ne sont pas des hackers, on peut s'attendre à ce qu'ils
utilisent LE petit python qui circule... comme tout le monde.

Et encore une fois: la commande ``last'' affiche les derniers logins.

> 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.
Même sentiment.

> 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.
Intéressant! A tester!

> 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.
L'informatique c'est très simple, ce ne sont que des 1 et des 0.
Le truc, c'est qu'il y en a de plus en plus....

-- 
 Félix Hauri  -  <felix at f-hauri.ch>  -  http://www.f-hauri.ch