<<< Date Index >>>     <<< Thread Index >>>

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@testlab-suse[~]: grep test /etc/shadow

[password is "test123"]

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

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

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

root@testlab-suse[~]: passwd test
Changing password for test.
New Password:
Reenter New Password:
Password changed.
root@testlab-suse[~]: grep test /etc/shadow

[password has been manually changed to "test321"]

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

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

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


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