BugTraq
Re: yet another OpenSSH timing leak? Oct 10 2006 07:56PM
Marco Ivaldi (raptor 0xdeadbeef info)
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

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus