Contexte et découverte

Le logiciel de bureau Omarchy a été publié avec l'utilisateur système ajouté au groupe docker. Cette configuration apparaît dès l'installation initiale et a été confirmée par le chercheur qui a signalé le problème en privé. Les versions concernées s'étendent de la 3.8.4 à la 4.0.0, soit plus d’un an de diffusion.

Le groupe Docker est traditionnellement réservé aux administrateurs système, car il octroie un accès complet aux API du démon Docker. Dans le cas d’Omarchy, l’ajout était documenté uniquement dans les scripts d’installation, sans avertissement de sécurité, ce qui a laissé la porte ouverte à une exploitation systématique.

Mécanisme d'escalade via le groupe Docker

Sur les systèmes Linux, l'appartenance au groupe docker confère l'accès en lecture‑écriture au socket /var/run/docker.sock, qui est possédé par root. Les groupes supplémentaires sont hérités par tous les processus d’une session graphique ; ainsi, chaque application lancée dans le bureau (navigateurs, éditeurs, scripts npm, agents d’IA) hérite du droit d’interroger le socket Docker. En invoquant l’API Docker, un processus peut monter le système de fichiers hôte avec les privilèges root sans demander de mot de passe ni afficher d’invite.

Le montage du répertoire racine via l’option -v /:/hostfs:ro ou -v /:/hostfs permet à un conteneur de parcourir l’ensemble du disque, de lire les fichiers /etc/shadow, les clés privées ou les jetons d’authentification stockés dans le profil utilisateur. Cette capacité contourne les mécanismes de confinement du conteneur, rendant la séparation entre hôte et container ineffective.

Impact et portée

Cette chaîne de confiance transforme une compromission d’application ordinaire en prise de contrôle totale du poste. Un malware injecté dans un navigateur peut, via le socket, créer un conteneur privilégié, monter / et modifier des fichiers système, installer des rootkits ou extraire des secrets. La vulnérabilité affecte tous les environnements où Omarchy est déployé, y compris les postes de travail d’entreprise, et ne dépend pas d’une configuration réseau particulière.

En pratique, un acteur malveillant peut automatiser la création de conteneurs qui exécutent des scripts de persistance (par ex. ajout d’un compte root dans /etc/passwd) ou qui déploient des agents de télécommande sur le réseau interne. La visibilité de ces actions est réduite, car les opérations Docker sont souvent exclues des journaux d’audit standard, ce qui complique la détection.

Correction et recommandations

Omarchy a retiré l’appartenance au groupe Docker dans la version 4.0.1. Les administrateurs doivent mettre à jour immédiatement les installations, vérifier la présence du groupe docker dans /etc/group pour l’utilisateur Omarchy, et, si nécessaire, supprimer cette entrée.

En parallèle, il est recommandé de restreindre l’accès au socket Docker à des comptes dédiés, d’activer des politiques de contrôle d’accès (AppArmor, SELinux) et de surveiller les appels au socket via auditd. Le passage à Docker en mode « rootless » ou l’utilisation de namespaces d’utilisateurs réduit l’impact d’un accès au socket. Enfin, l’intégration d’une journalisation détaillée des appels Docker dans les SIEM permet de détecter rapidement les montages inhabituels du système de fichiers hôte.