bugtraq - Re: yet another OpenSSH timing leak?

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>] [day] [month] [year] [list]

Date: Tue, 10 Oct 2006 21:56:10 +0200 (CEST)
From: Marco Ivaldi <raptor@...eadbeef.info>
To: bugtraq@...urityfocus.com
Subject: 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