full-disclosure - OpenSSH again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: listuser at seifried.org (Kurt Seifried)
Subject: OpenSSH again - not really.

 It looks possibly exploitable, but it needs privsep disabled. Many vendors
now enable privsep by default (in my opinion if a vendor does not or can not
enable privsep by default they have a misconfigured/broken OpenSSH package).
The workaround is pretty trivial, make sure the following line occurs in
your sshd config file:

UsePrivilegeSeparation yes

On recent Red Hat Linux versions and many others this is the default. You
can check that privsep is working, log in via ssh and do a process listing,
for each ssh connection you should see a pair of processes:

root     32624  0.0  0.1  6752 1916 ?        S    16:06   0:00
/usr/sbin/sshd
seifried 32626  0.0  0.2  6776 2156 ?        R    16:06   0:00
/usr/sbin/sshd

or

root     28354  0.0  0.1   372  1008 ??  Is     3:43PM    0:00.03 sshd:
seifried [priv] (sshd)
seifried 15019  0.0  0.1   416   912 ??  S      3:43PM    0:00.85 sshd:
seifried@...p0 (sshd)

As opposed to just one process running as root. Use privsep, be happy, don't
worry.

Kurt Seifried, kurt@...fried.org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/