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
test:$2a$05$OE8sRobsfoZVO137cEiSDe1fQ8L1fSk2KiuCJ7VkAyAZzsU8F/uWu:13433:0:99999:7:-1::
[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
test:$2a$10$KZFZX7yYEpbfDvwP6Z5N5ut4Gc/rdIF64/TmpWssIPQvROTiK/TiG:13433:0:99999:7:::
[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
root@testlab-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