Old history

I am the current maintainer of OpenSSH for FreeBSD, and have been since 2002. I am also the author and maintainer of the PAM implementation used by FreeBSD, and of several of the accompanying PAM modules. Finally, I was a member of the FreeBSD Security Team for several years, served as Assistant Security Officer and Acting Security Officer, and authored or co-authored around 20 security advisories between 2002 and 2004.

I have been asked to comment on SecurityFocus advisories 7467 and 7482, regarding timing attacks against certain versions of OpenSSH that were distributed with FreeBSD 4.x and 5.x releases.

The short version is that no FreeBSD 4.x or 5.x release was ever vulnerable. Read on for the long version.

The two issues are closely related, albeit not identical. They both allow an attacker to confirm information that they already have, or that they have guessed, and the attack mechanism is roughly the same. In both cases, a different code path is taken depending on the outcome of the authentication process. In the affected versions of OpenSSH, there are three possible outcomes:

1. non-existent user: no attempt to verify password
2. existent user, wrong password: authentication fails
3. existent user, correct password: authentication succeeds

Additionally, the user may be administratively blocked—for instance, if PermitRootLogin is off, root will not be able to log in at all. This is the default in FreeBSD.

An attacker that can distinguish between cases 1 and 2 can verify that a particular user exists on the target system. This is the core of issue 7467.

An attacker that can distinguish between cases 2 and 3, even if they do not ultimately gain access, can verify that a particular password is correct for a particular user on the target system. This is the core of issue 7482.

Outwardly, OpenSSH will behave in the exact same manner in all three cases: if you try to log in as a non-existent user, or as a user that is administratively blocked, you will still be asked for your password.

Internally, however, the code paths are different. In case 1, OpenSSH will not invoke PAM authentication to verify the password provided by the client, since it already knows the outcome. In cases 2 and 3, it will invoke PAM authentication. The attack relies on being able to determine whether PAM authentication was invoked, and whether it was successful, even if you are unable to log in.

Here is the crux of the matter: some operating systems have PAM modules that will delay for two seconds when authentication fails. Therefore:

• An attacker that attempts to log on as a particular user with a made-up password will see a two-second delay after each password prompt if and only if the user exists.
• An attacker that attempts to log on as a user which they know exists, but which is administratively blocked (e.g. root, see above), will see a two-second delay after each password prompt if and only if they typed the wrong password.

FreeBSD’s PAM modules do not delay when authentication fails. There will still be minute differences in timing, but they will be too small to measure across the network.

Therefore, FreeBSD is not vulnerable to these attacks.

Finally, I should mention that the first issue was addressed in OpenSSH 3.6.1p2 by invoking PAM authentication even for non-existent users, and the second in OpenSSH 3.9p1 by passing an invalid password to PAM when someone tries to log in as root on a system where RootPermitLogin is off.

[edited for clarity on 2008-08-04]