26 lines
No EOL
1.4 KiB
Text
26 lines
No EOL
1.4 KiB
Text
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1010
|
|
|
|
This issue affects OpenSSH if privilege separation is disabled (config option
|
|
UsePrivilegeSeparation=no). While privilege separation is enabled by default, it
|
|
is documented as a hardening option, and therefore disabling it should not
|
|
directly make a system vulnerable.
|
|
|
|
OpenSSH can forward TCP sockets and UNIX domain sockets. If privilege separation
|
|
is disabled, then on the server side, the forwarding is handled by a child of
|
|
sshd that has root privileges. For TCP server sockets, sshd explicitly checks
|
|
whether an attempt is made to bind to a low port (below IPPORT_RESERVED) and, if
|
|
so, requires the client to authenticate as root. However, for UNIX domain
|
|
sockets, no such security measures are implemented.
|
|
|
|
This means that, using "ssh -L", an attacker who is permitted to log in as a
|
|
normal user over SSH can effectively connect to non-abstract unix domain sockets
|
|
with root privileges. On systems that run systemd, this can for example be
|
|
exploited by asking systemd to add an LD_PRELOAD environment variable for all
|
|
following daemon launches and then asking it to restart cron or so. The attached
|
|
exploit demonstrates this - if it is executed on a system with systemd where
|
|
the user is allowed to ssh to his own account and where privsep is disabled, it
|
|
yields a root shell.
|
|
|
|
|
|
Proof of Concept:
|
|
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40962.zip |