Dropbear permitopen/permitlisten bypass via unix-socket forwarding — docker.sock reachable
Severity: critical · Patch status: unpatched · Since 2026-11-13
A logic flaw in Dropbear SSH lets a restricted authorizedkeys key bypass per-destination forwarding restrictions via unix-socket forwarding. TCP forwarding correctly enforces permitopen/permitlisten, but the streamlocal (unix socket) paths in svr-streamfwd.c only check the coarse no-port-forwarding flag, never the per-destination lists. A 2024 commit claimed to apply TCP forwarding restrictions to unix sockets but only added the coarse gate. Live-proven against HEAD 99baf182 (2026-11-11): a key restricted to permitopen="127.0.0.1:1" opened a direct-streamlocal channel to /tmp/target.sock and to /var/run/docker.sock, issuing Docker API requests (host-root-equivalent reach). Affected: routers, embedded systems, appliances running Dropbear with restricted keys and reachable unix sockets. No fix exists; suggested mitigation is refusing streamlocal channels for keys carrying per-destination restrictions.
What to do
- Audit authorized_keys for keys carrying permitopen/permitlisten restrictions on Dropbear servers and treat them as unrestricted for unix-socket forwarding until patched
- Remove unix-socket forwarding capability for restricted accounts (e.g. disable DROPBEAR_SVR_LOCALSTREAMFWD/REMOTESTREAMFWD at build time or restrict via server options)
- Restrict OS-level access to sensitive unix sockets (docker.sock, database sockets) for accounts holding restricted SSH keys — e.g. remove from docker group
- Monitor for direct-streamlocal@openssh.com and streamlocal-forward@openssh.com channel requests in Dropbear logs
- Track upstream Dropbear for a fix adding path-based permit restrictions in svr-streamfwd.c
Sources
All live incidents on Threat Watch
