Re: yet another OpenSSH timing leak?
Hey again,
I know quoting myself is bad form, but i just wanted to clarify a few
points about my recent OpenSSH timing leak post;)
Here we are again... During a recent penetration test i stumbled upon
yet another OpenSSH timing leak, leading to remote disclosure of valid
usernames. It's not as big as the one i found in the past
(CVE-2003-0190), but it can indeed be exploited over the Internet,
nevertheless.
Since some people asked me, i can confirm this exposure is not directly
related to the old OpenSSH-portable/PAM timing leak (CVE-2003-0190), nor
to the recent GSSAPI vulnerability (CVE-2006-5052), though my script can
help to exploit both of them.
So far, i've not been able to determine the root cause of this exposure
and i've reproduced it only on some fully-patched SUSE Linux 10.0 boxes
(OpenSSH_4.1 + SUSE patches, both protocols 1 and 2 are affected, with
or without PAM authentication), therefore it may be a SUSE-specific
and/or a configuration-dependant flaw (latest tests on some freshly
installed SUSE systems didn't show the flawed behaviour).
I'm still investigating the cause of the problem.
Since i couldn't reproduce it on a fresh SUSE install, i thought it might
depend on some special configuration adopted on the pen-tested boxen: so
far, i can say it doesn't seem to depend on 32-bit/64-bit installs, nor on
IPv4/IPv6 support, nor on PAM/noPAM (i found vulnerable systems with all
combinations of these configurations).
Although i'm not able to tell what exactly makes a system vulnerable,
logging is one of the most promising culprit candidates. Stracing sshd
it's easy to spot the different codepaths, and playing with timing options
-t, -T, and -r leads to some interesting results. I'll dig a bit more into
this and let you know if i come up with something interesting.
That said, there are probably other timing leaks involving third-party
patches (x509 certs, LDAP, and so on), logging, and custom
configurations, as well as other ways in which valid usernames may be
probed for (i.e., with RSA/DSA authentication) -- thus i decided to
release a small script for testing timing patterns in sshd replies:
Even if at the end of testing it turns out that the exposure i found is
highly dependant on configuration (therefore not deserving a CVE/BID
entry), i hope the small sshtime script will help researchers and auditors
to spot some other timing leaks.
Cheers,
--
Marco Ivaldi
Antifork Research, Inc. http://0xdeadbeef.info/
3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707