Re: yet another OpenSSH timing leak?
- From: Marco Ivaldi <raptor@xxxxxxxxxxxxxxx>
- Date: Tue, 10 Oct 2006 21:56:10 +0200 (CEST)
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
- Prev by Date: [Fedora] libtool-ltdl uses relative paths to resolve and load libraries
- Next by Date: [SECURITY] [DSA 1195-1] new openssl096 packages fix denial of service
- Previous by thread: Re: yet another OpenSSH timing leak?
- Next by thread: Re: yet another OpenSSH timing leak?
- Index(es):
Relevant Pages
|
