
Linux privilege escalation via LXD
Les membres du groupe local lxd sur les systèmes Linux disposent de nombreuses voies pour élever leurs privilèges jusqu'à root. Ce dépôt contient des exemples d'exploits locaux entièrement automatisés pour devenir root. Une explication détaillée de la vulnérabilité et une procédure pas à pas de l'exploit sont disponibles dans mon blog ici.
Les exploits ci-dessous ne sont pas des évasions de conteneurs, mais des exploits locaux qui tirent parti des conteneurs et ciblent le système hôte. Un accès à faible privilège sur l'environnement hôte est nécessaire pour une exploitation réussie.
Je crois que ma stratégie avec la version 2 de l'exploit est unique, et a été suffisamment intéressante (du moins pour moi) pour que j'écrive une explication détaillée dans le blog lié ci-dessus.
lxd_rootv1.sh monte le système de fichiers / de l'hôte dans un conteneur, où l'utilisateur à faible privilège de l'hôte dispose d'un accès root. Cet accès root se répercute sur l'hôte, permettant d'ajouter l'utilisateur actuel au fichier /etc/sudoers. Cela a été exploité par d'autres avant moi.lxd_rootv2.py monte le socket UNIX privé de systemd de l'hôte dans un conteneur puis le remonte vers l'hôte via des périphériques proxy LXD. Ces périphériques proxy ont des privilèges root, et ils transmettent leurs identifiants lors des communications sur le socket, contrairement aux identifiants de l'utilisateur à faible privilège initiateur. Cela est abusé pour créer un service systemd temporaire qui ajoute l'utilisateur actuel au fichier /etc/sudoers.Les deux exploits nécessitent un conteneur, créez-en d'abord un. Ensuite, exécutez l'exploit depuis le système d'exploitation hôte avec le nom du conteneur comme premier argument.
# Exploit with v1
$ bash lxd_rootv1.sh <container name>
# Exploit with v2
$ python3 lxd_rootv2.py <container name>

Avant que je ne tombe sur ces problèmes, rien dans la documentation officielle de LXD n'existait pour avertir les utilisateurs que le groupe lxd était dangereux. Toute personne suivant les directives officielles pour configurer LXD aurait ajouté son compte à ce groupe avant de déployer son premier conteneur. J'ai ouvert un bug chez Canonical pour exprimer mes préoccupations - vous pouvez lire le fil complet ici. L'équipe LXD a rapidement apporté des ajustements à la documentation, qui indique désormais clairement que ce groupe ne doit être donné qu'à ceux en qui on a confiance pour un accès root.
Comme toujours, interagir avec les gens de Canonical via leur suivi de bugs a été une expérience très agréable. Je tiens à les remercier pour leur temps et pour la considération réfléchie qu'ils ont accordée à mes idées. Je recommande vivement aux autres chercheurs en sécurité de leur soumettre directement des problèmes de cette manière.
Je ne suis pas la première personne à exploiter LXD. Cela a été soulevé comme une préoccupation dans plusieurs tickets GitHub remontant à 2016 :
Ce premier lien est la première personne (simpoir) à avoir identifié ce risque, pour autant que je sache.
@reboare a écrit un bon blog sur l'exploitation de LXD en utilisant la même méthode que mon exploit v1, bien avant moi :
Merci aux gens de LXD d'avoir créé un outil très cool. J'utilise personnellement LXD et je l'aime beaucoup. Je ne pense pas que ce soit un obstacle à l'utilisation de LXD, je pense qu'il est simplement très important de comprendre le risque potentiel lors de l'ajout d'utilisateurs au groupe lxd.
Il n'existe pas de correctif officiel pour ces vulnérabilités. Toute personne utilisant LXD doit être consciente qu'ajouter des utilisateurs au groupe lxd revient essentiellement à leur donner les droits root.
Si vous utilisez LXD sur un hôte mono-utilisateur, comme un bureau, il peut être préférable de ne pas utiliser du tout le groupe lxd et d'exécuter sudo lorsque vous devez communiquer avec l'API.
Pour les environnements partagés avec plusieurs personnes travaillant sur des conteneurs, il peut être préférable de créer des environnements imbriqués. Chaque utilisateur individuel du groupe LXD pourra exploiter son propre environnement mais devra ensuite travailler plus dur pour s'échapper de ce conteneur afin d'exploiter les autres.