Dropbear : un contournement des restrictions SSH atteint les sockets root

En bref

• Dropbear applique permitopen et permitlisten au transfert TCP mais pas au transfert de sockets Unix. Une clé restreinte à une destination TCP peut ouvrir n'importe quel socket accessible au compte.
• Toutes les versions de Dropbear jusqu'à 2026.94 et la HEAD Git 99baf182 sont concernées. Les options de transfert de flux local et distant sont activées par défaut.
• Le chercheur knell la note 9,9 lorsque le compte peut atteindre le démon Docker ou un socket de base de données. Aucune CVE n'est attribuée, aucune exploitation n'est signalée, et elle n'est pas dans le catalogue KEV de la CISA au 14 novembre 2026.
• Aucune version corrigée n'existe. Ajoutez no-port-forwarding aux clés restreintes, ou recompilez Dropbear avec les options de transfert de flux désactivées. Voir « Comment corriger ? » pour le coût de chaque option.

Suis-je concerné ?

Vous êtes exposé lorsque toutes les conditions suivantes sont réunies :

• Le serveur exécute Dropbear, toutes versions ou HEAD Git jusqu'à 99baf182 (2026-11-11).
• La compilation garde le transfert de sockets Unix activé. DROPBEAR_SVR_LOCALSTREAMFWD et DROPBEAR_SVR_REMOTESTREAMFWD valent 1 par défaut.
• Au moins une entrée authorized_keys porte permitopen= ou permitlisten=. La restriction est la raison pour laquelle le porteur de la clé n'est pas jugé digne d'un accès général.
• Le compte derrière cette clé peut atteindre un socket Unix sensible, comme /var/run/docker.sock ou un socket de base de données. Le cas 9,9 du chercheur est le socket Docker.
• L'attaquant détient cette clé restreinte, ou peut utiliser le compte qui la détient.

Une clé sans restriction permitopen ou permitlisten n'est pas le sujet de cette faille : son porteur dispose déjà d'un accès général au transfert. Le contournement compte pour les clés qu'un administrateur a délibérément restreintes.

Vérifiez la version du serveur et les clés restreintes :

# Server and client version
dropbear -V

# Keys that carry a per-destination restriction
grep -R -E 'permitopen=|permitlisten=' /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null

# Accounts that can reach the Docker socket
getent group docker

La liste des clés est la vérification importante. Une clé permitopen dont le compte est aussi dans le groupe docker correspond au cas 9,9 décrit par le chercheur.

Comment corriger ?

Aucune version corrigée de Dropbear n'existe au 14 novembre 2026. Appliquez l'une des trois mesures suivantes, par ordre de préférence, et retirez-la lorsque le projet publiera un correctif fondé sur le chemin.

1. Ajoutez no-port-forwarding à chaque clé qui porte permitopen ou permitlisten. Les gestionnaires de transfert de flux vérifient cet indicateur via svr_pubkey_allows_tcpfwd(), donc la clé ne peut plus ouvrir de sockets Unix. Le coût est que la clé perd aussi tout transfert TCP, y compris la destination que l'administrateur avait autorisée.
2. Recompilez Dropbear avec DROPBEAR_SVR_LOCALSTREAMFWD 0 et DROPBEAR_SVR_REMOTESTREAMFWD 0 dans localoptions.h. Le coût est qu'aucun compte de ce serveur ne peut utiliser le transfert de sockets Unix.
3. Démarrez le serveur avec -j -k. Ces options activent nolocaltcp et noremotefwd, que les gestionnaires de transfert de flux vérifient. Le coût est que tous les comptes perdent le transfert local et distant, pas seulement les clés restreintes.

Retirer le compte du groupe docker et durcir les permissions des sockets réduit l'impact. Cela ne ferme pas le contournement : la clé peut encore atteindre tout autre socket que le compte peut ouvrir, notamment les sockets de bases de données et de services.

Le chercheur recommande un équivalent de permitopen fondé sur le chemin, appliqué dans svr-streamfwd.c avec le même parcours de liste que le chemin TCP. Surveillez la page de publication de Dropbear pour ce changement ; le projet n'a pas publié de version corrigée.

Quelle est la cause racine ?

Les gestionnaires de transfert de sockets Unix ne vérifient que l'indicateur global no-port-forwarding. Ils n'appellent jamais les fonctions qui parcourent la liste des destinations de la clé.

Dropbear conserve les restrictions dans authorized_keys. svr_pubkey_allows_tcpfwd() à la ligne 65 de src/svr-authpubkeyoptions.c renvoie 0 uniquement lorsque la clé porte no-port-forwarding :

int svr_pubkey_allows_tcpfwd() {
    if (ses.authstate.pubkey_options 
        && ses.authstate.pubkey_options->no_port_forwarding_flag) {
        return 0;
    }
    return 1;
}

Les contrôles par destination se trouvent dans svr_pubkey_allows_local_tcpfwd() et svr_pubkey_allows_remote_tcpfwd() dans le même fichier. src/svr-tcpfwd.c les appelle aux lignes 202 et 99. Les deux gestionnaires de transfert de flux ne le font pas.

Dans src/svr-streamfwd.c, le gestionnaire local newstreamlocal() vérifie svr_opts.nolocaltcp et svr_pubkey_allows_tcpfwd() à la ligne 294. Le gestionnaire distant svr_remotestreamlocalreq() vérifie svr_opts.noremotefwd et la même fonction à la ligne 219. Une recherche dans l'arborescence trouve les deux fonctions par destination référencées uniquement depuis src/svr-tcpfwd.c.

La compilation par défaut active les deux options de transfert de flux aux lignes 76 et 77 de src/default_options.h. Le canal est enregistré dans src/svr-session.c.

Le correctif incomplet est visible dans l'historique. Le commit 796a89ef (2024-04-03), « Apply tcp forwarding restrictions to unix sockets too », ajoute le contrôle global à newstreamlocal() et met à jour le manuel. Il n'ajoute pas le contrôle par destination que son titre annonce. L'auteur note aux lignes 213 et 214 de src/svr-streamfwd.c que le contrôle pourrait être assoupli si un équivalent de permitlisten existait pour streamlocal ; il n'existe pas.

Comment la faille est-elle exploitée ?

1. L'attaquant s'authentifie avec une clé que l'administrateur a restreinte à une destination TCP avec permitopen="host:port".
2. L'attaquant ouvre un canal direct-streamlocal@openssh.com vers un chemin de socket Unix au lieu d'une destination TCP.
3. Le gestionnaire de transfert de flux de Dropbear vérifie l'indicateur no-port-forwarding et l'interrupteur global de transfert. Les deux passent, car la clé ne porte pas no-port-forwarding.
4. Le gestionnaire ne consulte jamais la liste permitopen, donc il se connecte au socket demandé.
5. L'attaquant parle le protocole du socket. Sur /var/run/docker.sock, l'API Docker peut démarrer un conteneur avec le système de fichiers de l'hôte monté, ce qui équivaut à root sur l'hôte.

Le chercheur a démontré le contournement sur un banc local construit à partir de la source épinglée. Une clé portant permitopen="127.0.0.1:1" a été refusée lorsqu'elle demandait 127.0.0.1:22, mais la même clé a atteint /tmp/target.sock. La même clé a ensuite ouvert /var/run/docker.sock et reçu HTTP/1.1 200 OK, Api-Version 1.56 du vrai démon.

La direction distante fonctionne de la même manière. Une clé avec permitlisten peut faire écouter le serveur sur un chemin Unix inscriptible arbitraire et masquer un socket de service.

Comment se déroule l'attaque ?

Une clé restreinte passe le contrôle global de transfert, demande un socket Unix au lieu d'une destination TCP, et atteint un socket que l'administrateur n'a jamais autorisé.

Que peut faire un attaquant ?

L'attaquant atteint les sockets Unix que le compte peut ouvrir, alors que la clé était restreinte à une destination TCP. Lorsque le compte peut atteindre le socket Docker, cela équivaut à root sur l'hôte.

L'impact dépend des sockets que l'identité système du compte peut toucher :

• /var/run/docker.sock permet à l'attaquant de lancer un conteneur avec le système de fichiers de l'hôte monté en root. Le chercheur qualifie cela d'équivalent à root sur l'hôte.
• Les sockets de bases de données comme /run/mysqld/mysqld.sock et /run/postgresql/.s.PGSQL.5432 exposent la base au porteur de la clé.
• Les sockets d'agents et de services exposent ce que ces services acceptent.
• Dans la direction permitlisten, l'attaquant peut faire écouter le serveur sur un chemin inscriptible arbitraire et masquer un socket de service.

Les conditions font partie de l'impact : l'attaquant a besoin d'une clé restreinte valide. Le compte doit pouvoir ouvrir le socket cible, et la compilation doit garder le transfert de flux activé. Le chercheur note le cas Docker CVSS v3.1 9,9 avec AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, et environ 7 lorsque seuls les sockets du compte sont atteignables.

Ce n'est pas une faille non authentifiée. L'attaquant détient une clé que l'administrateur a délivrée, et l'administrateur l'a restreinte précisément pour limiter ce que cette clé peut faire.

Pourquoi le correctif fonctionne-t-il ?

Aucun correctif amont n'existe encore. Le changement qui ferme le contournement applique aux deux gestionnaires de transfert de flux le même parcours de liste par destination que les gestionnaires TCP utilisent déjà.

Le contrôle manquant est visible dans les deux gestionnaires. Le gestionnaire local à la ligne 294 de src/svr-streamfwd.c lit actuellement :

if (svr_opts.nolocaltcp || !svr_pubkey_allows_tcpfwd()) {

Un contrôle complet appellerait aussi un équivalent fondé sur le chemin de svr_pubkey_allows_local_tcpfwd() pour le chemin de socket demandé. Il rejetterait le canal lorsque la clé porte une liste de destinations qui ne l'inclut pas. Le gestionnaire distant à la ligne 219 a besoin du même changement pour permitlisten.

La recommandation du chercheur est de refuser d'emblée les canaux streamlocal pour toute clé qui porte une restriction par destination. Cette règle s'applique jusqu'à ce qu'une option fondée sur le chemin existe. C'est le correctif prudent et il est simple à raisonner : une clé qui nomme des destinations n'obtient pas de sockets Unix.

La mesure no-port-forwarding fonctionne parce qu'elle active l'indicateur que lit le contrôle global existant. Les mesures de compilation et -j -k fonctionnent parce qu'elles activent les interrupteurs globaux que lisent les gestionnaires. Aucune n'est un correctif de code pour le parcours de liste manquant.

Comment vérifier si j'ai été compromis ?

Aucune exploitation n'a été signalée et aucun indicateur de compromission n'a été publié. Les vérifications portent sur les conditions et l'usage des sockets, pas sur une charge utile connue.

• Listez chaque clé qui porte permitopen ou permitlisten, et le compte qui la détient.
• Vérifiez si ces comptes sont dans le groupe docker ou peuvent ouvrir des sockets de bases de données.
• Examinez les journaux d'audit du démon Docker pour des appels d'API provenant de processus ou d'utilisateurs locaux inattendus, surtout les créations de conteneurs avec des montages de l'hôte.
• Examinez les journaux des bases de données pour des connexions par socket local provenant d'utilisateurs système qui ne se connectent pas normalement.
• Cherchez des conteneurs, images ou montages que personne dans l'équipe n'a créés.

La journalisation par défaut de Dropbear est minimale, et l'analyse ne publie aucune signature de journal. Une tentative échouée peut ne laisser aucune trace, et une tentative réussie laisse ses effets dans le service auquel appartient le socket.

Chronologie

• 2024-04-03 : le commit 796a89ef applique la restriction globale de transfert TCP aux sockets Unix, mais pas les contrôles par destination.
• 2025-12-09 : le commit 00cfa132 bloque le transfert de flux Unix pour les clés à commande forcée, une restriction différente sur le même chemin.
• 2026-07-23 : Dropbear publie 2026.94.
• 2026-11-11 : le chercheur teste la HEAD Git 99baf182 ; le contournement est présent.
• 2026-11-13 : le chercheur publie l'analyse et la preuve en direct sur la liste oss-security.

FAQ

Existe-t-il une CVE pour cette faille ?

Non. Le chercheur a publié l'analyse sur la liste oss-security le 13 novembre 2026, et aucun enregistrement CVE n'existe au 14 novembre. Le projet Dropbear n'a publié aucun avis.

permitopen protège-t-il les sockets Unix ?

Non. permitopen et permitlisten ne sont appliqués que sur les chemins de transfert TCP. Les gestionnaires de sockets Unix vérifient l'indicateur no-port-forwarding et l'interrupteur global de transfert, pas la liste des destinations.

S'agit-il d'une faille distante non authentifiée ?

Non. L'attaquant a besoin d'une clé valide que l'administrateur a restreinte avec permitopen ou permitlisten. La gravité dépend de ce que le compte derrière cette clé peut atteindre.

Quelles versions sont concernées ?

Toutes les versions de Dropbear jusqu'à 2026.94 et la HEAD Git jusqu'à 99baf182 (2026-11-11). Aucune version corrigée n'existe au 14 novembre 2026.

no-port-forwarding bloque-t-il le contournement ?

Oui. no-port-forwarding active l'indicateur que lit svr_pubkey_allows_tcpfwd(), donc les deux gestionnaires de transfert de flux refusent le canal. Il bloque aussi tout transfert TCP pour cette clé, y compris la destination autorisée.

Et si le compte n'est pas dans le groupe docker ?

L'attaquant peut quand même atteindre tout socket que le compte peut ouvrir, comme un socket de base de données ou de service. L'impact est inférieur à root sur l'hôte, mais il reste un accès que la restriction de la clé devait empêcher.

Références

• knell, « Dropbear: the restriction names an address », oss-security, 13 novembre 2026, l'analyse et la preuve en direct : https://www.openwall.com/lists/oss-security/2026/11/13/4 (vérifié le 14 novembre 2026)
• L'article du chercheur, « Not an address », l'analyse complète et le banc de test : https://archive.org/details/knell-not-an-address (vérifié le 14 novembre 2026)
• Source Dropbear à 99baf182, src/svr-streamfwd.c, les deux gestionnaires de transfert de flux : https://github.com/mkj/dropbear/blob/99baf1828c13e88de048e641d03694bfe8923251/src/svr-streamfwd.c (vérifié le 14 novembre 2026)
• Source Dropbear à 99baf182, src/svr-authpubkeyoptions.c, le contrôle global et les contrôles par destination : https://github.com/mkj/dropbear/blob/99baf1828c13e88de048e641d03694bfe8923251/src/svr-authpubkeyoptions.c (vérifié le 14 novembre 2026)
• Source Dropbear à 99baf182, src/default_options.h lignes 76 et 77, les valeurs par défaut du transfert de flux : https://github.com/mkj/dropbear/blob/99baf1828c13e88de048e641d03694bfe8923251/src/default_options.h (vérifié le 14 novembre 2026)
• Commit 796a89ef, « Apply tcp forwarding restrictions to unix sockets too », 3 avril 2024 : https://github.com/mkj/dropbear/commit/796a89efd21f (vérifié le 14 novembre 2026)
• Commit 00cfa132, « Disallow unix stream forwarding for forced command », 9 décembre 2025 : https://github.com/mkj/dropbear/commit/00cfa132fcbf (vérifié le 14 novembre 2026)
• Page du projet Dropbear, le cas d'usage embarqué et routeur et la version 2026.94 : https://matt.ucc.asn.au/dropbear/dropbear.html (vérifié le 14 novembre 2026)
• Catalogue Known Exploited Vulnerabilities de la CISA, vérifié pour une entrée Dropbear le 14 novembre 2026 (aucune) : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (vérifié le 14 novembre 2026)