Date: Sat, 14 Oct 2006 20:10:23 +0200 (CEST)
From: Marco Ivaldi <raptor@...eadbeef.info>
To: bugtraq@...urityfocus.com
Subject: Re: yet another OpenSSH timing leak?

Hey Bugtraq,

I'm re-sending this to the list, 'cause for some reason my previous email 
didn't go through... Here's further information about the OpenSSH timing 
leak i recently found on SUSE systems, plus some news and considerations 
about possible solutions.

First of all, i finally managed to reproduce the vulnerability on a fresh 
SUSE 10.0 install: the sshd process has a peak in CPU usage while 
processing user credentials stored in /etc/shadow, only for those 
usernames whose password has been set manually, i.e. not using yast.

Take a look at the following example:

[add a new user "test" using yast]

root@...tlab-suse[~]: grep test /etc/shadow
test:$2a$05$OE8sRobsfoZVO137cEiSDe1fQ8L1fSk2KiuCJ7VkAyAZzsU8F/uWu:13433:0:99999:7:-1::

[password is "test123"]

root@...tlab-suse[~]: ./sshtime localhost dict

sshtime v0.1 - Simple OpenSSH remote timing attack tool
Copyright (c) 2006 Marco Ivaldi <raptor@...eadbeef.info>

test@...alhost          real 1.23 <- no delay (it's even a bit faster;)
aaaa@...alhost          real 1.27

root@...tlab-suse[~]: passwd test
Changing password for test.
New Password:
Reenter New Password:
Password changed.
root@...tlab-suse[~]: grep test /etc/shadow
test:$2a$10$KZFZX7yYEpbfDvwP6Z5N5ut4Gc/rdIF64/TmpWssIPQvROTiK/TiG:13433:0:99999:7:::

[password has been manually changed to "test321"]

root@...tlab-suse[~]: ./sshtime localhost dict

sshtime v0.1 - Simple OpenSSH remote timing attack tool
Copyright (c) 2006 Marco Ivaldi <raptor@...eadbeef.info>

test@...alhost          real 2.18 <- we can observe a big delay!
aaaa@...alhost          real 1.27

root@...tlab-suse[~]:

These tests were performed on both fully-patched and not patched SUSE 10.0 
boxes, with sshd configured not to use PAM, although this same exposure 
has been identified also on PAM-enabled systems, with minor differences. I 
have no idea if older/newer SUSE versions are also vulnerable. Therefore, 
to summarize things up: it's possible to remotely identify usernames whose 
password has been set manually -- this is a SUSE-specific exposure, that 
should be fixed by SUSE developers.

The root cause of the flawed behaviour is easy to spot. For instance:

"The version number, the logarithm of the number of rounds and the 
concatenation of salt and hashed password are separated by the `$' 
character [in /etc/shadow]. An encoded `8' would specify 256 rounds".
         -- OpenBSD crypt(3) manual page

The manually entered password has a bigger logarithm of the number of 
rounds ("10"), thus it takes much more time to process, depending on CPU 
power.

This suggests the obvious workaround and means other distros/OSes (like 
OpenBSD) that use blowfish crypt() might be vulnerable as well... 
Specifically, quoting Solar Designer, "this affects all platforms that do 
not bother to compute password hashes with fake salts for non-existent 
accounts and/or to use the same iteration count in those fake salts that 
is used for real passwords".

Moreover, "it means that this should affect those platforms that use 
MD5-based hashes, too - only to a lesser extent (since those hashes are 
faster). And it should be possible to spot the "$2a$05$" (quicker to 
compute) hashes on SuSE, too, compared to non-existent accounts - one just 
has to do more probes per-account". Take a look at how Owl resolves this.

Now the news. This is not the only instance of timing and other leaks of 
information on whether a username is valid. Beside the flaw described 
above, off-list email reports i got so far seem to confirm there are quite 
some different previously unknown/unreleased timing leaks in OpenSSH, on 
various Linux distributions and operating systems: some of them are there 
by default, others may depend on environment, configuration, or 
third-party patches (LDAP patch), and so on... I bet commercial SSH 
implementations are not safe as well.

Unfortunately, it's a very broad topic and it's not easy to find a valid 
solution without careful large-scale testing. Moreover, as Solar Designer 
put it, it's everyone's and noone's fault -- or arguably not a fault at 
all, but just the way things work. Nevertheless, i believe big timing 
leaks which are exploitable over the Internet should definitely be taken 
care of by developers.

PS. The CVE Project has assigned candidate number CVE-2006-5229 to this 
issue.

-- 
Marco Ivaldi
Antifork Research, Inc.   http://0xdeadbeef.info/
3B05 C9C5 A2DE C3D7 4233  0394 EF85 2008 DBFD B707

Powered by blists - more mailing lists