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]

3 thoughts on “Old history”

  1. Dear DES-

    Thanks for taking the time to clarify
    this history.

    The world of developers travels much
    faster than deployments, so history
    remains valuable after the code has
    moved on!

    Also, there are “dumb” scanners that
    trigger only on the OpenSSH version,
    without considering the underlying
    OS – in this case FreeBSD.

    We appreciate your attention to this

    -Mr. Math and Friends

  2. Actually, there is no need for the scanner to “consider the underlying OS”, at least for 7467:

    1) Try to log in with a randomly-generated user name (include a colon for good measure) and a randomly-generated password. Measure the average time elapsed between password prompts.

    2) Try to log in as an existing user (root is fine) with a randomly-generated password. Measure the average amount of time between password prompts.

    If 2) takes significantly longer than 1), the target is vulnerable to 7467.

    If the target is vulnerable 7467, or 1) and 2) can be measured in seconds rather than milliseconds, the target may also be vulnerable to 7482.

  3. You have a blog! I didn’t know that. I linked to it from my blog (just to make it look like I have at least some friends ;-).

    I have no earthly idea what this post is about, but thanks for sharing. ;-)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.