Bug 90799 - CAN-2003-0190 OpenSSH/PAM timing attack
CAN-2003-0190 OpenSSH/PAM timing attack
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
http://cve.mitre.org/cgi-bin/cvename....
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-13 18:24 EDT by Jesse Throwe
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-02 05:38:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jesse Throwe 2003-05-13 18:24:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020929

Description of problem:
Security Advisory                     @ Mediaservice.net Srl
(#01, 30/04/2003)                    Data Security Division

        Title:    OpenSSH/PAM timing attack allows remote users identification
  Application:    OpenSSH-portable <= 3.6.1p1
     Platform:    Linux, maybe others
  Description:    A remote attacker can identify valid users on vulnerable
        systems, all PAM-enabled systems are potentially affected
       Author:    Marco Ivaldi <raptor@mediaservice.net>
 Contributors: Maurizio Agazzini <inode@mediaservice.net>,
        Solar Designer <solar@openwall.com>,
        Andrea Ghirardini <pila@pilasecurity.com>
Vendor Status: OpenSSH team notified on 12/04/2003,
        vendor-sec list notified on 28/04/2003
CVE Candidate: The Common Vulnerabilities and Exposures project has assigned
        the name CAN-2003-0190 to this issue.
   References: http://lab.mediaservice.net/advisory/2003-01-openssh.txt
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0190

1. Abstract.

During a pen-test we stumbled across a nasty bug in OpenSSH-portable with PAM
support enabled (via the --with-pam configure script switch). This bug allows a
remote attacker to identify valid users on vulnerable systems, through a simple
timing attack. The vulnerability is easy to exploit and may have high severity,
if combined with poor password policies and other security problems that allow
local privilege escalation.

2. Example Attack Session.

root@voodoo:~# ssh [valid_user]@lab.mediaservice.net
[valid_user]@lab.mediaservice.net's password:    <- arbitrary (non-null) string
[2 secs delay]
Permission denied, please try again.

root@voodoo:~# ssh [no_such_user]@lab.mediaservice.net
[no_such_user]@lab.mediaservice.net's password:    <- arbitrary (non-null) string
[no delay]
Permission denied, please try again.

3. Affected Platforms.

All vendors supporting Linux-PAM are potentially affected. This includes:

* Debian GNU/Linux        [confirmed in the default install]
* Red Hat Linux            [confirmed in the default install]
* Mandrake Linux        [confirmed in the default install]
* SuSE Linux             [not confirmed in the default install]
* Caldera/SCO Linux        [not confirmed in the default install]
* Apple OS-X            [not confirmed in the default install]
* MSC.Linux            [not confirmed in the default install]

NOTE. FreeBSD uses both a different PAM implementation and a different PAM
support in OpenSSH: it doesn't seem to be vulnerable to this particular timing
leak issue.

All OpenSSH-portable releases <= OpenSSH_3.6.1p1 compiled with PAM support
enabled (./configure --with-pam) are vulnerable to this information leak. The
PAMAuthenticationViaKbdInt directive doesn't need to be enabled in sshd_config.

4. Fix.

There is currently no complete fix to this. Moreover, there are many smaller
timing leaks which too are easy to use to obtain the same information. These are
primarily in OpenSSH and in the system libraries (getpwnam(3), NSS modules, and
so on). Solving this kind of timing leaks requires a re-design of the
authentication code paths (partially in OpenBSD tree and partially only in
-portable).

Solar Designer has written an OpenSSH-portable patch for Openwall GNU/*/Linux
(http://www.openwall.com/Owl/) that makes OpenSSH always run PAM with password
authentication, even for non-existent or not allowed usernames, thus fixing the
bigger problem outlined in this advisory. Please note that this patch merely
reduces the timing leaks without fully removing them. Other OpenSSH patches from
the Owl project are available via:

cvs -d :pserver:anoncvs:anoncvs@anoncvs.owl.openwall.com:/cvs co
Owl/packages/openssh

The OpenSSH team has released OpenSSH 3.6.1p2, which includes the changes
introduced by Openwall GNU/*/Linux. All OpenSSH-portable users are encouraged
to upgrade.

Our team (with the contribution of Andrea Ghirardini) has been able to find a
valid workaround for the specific timing leak mentioned in this advisory: just
add the "nodelay" option to the pam_unix.so auth configuration. 
This is a modified (not vulnerable) configuration for Red Hat Linux (notice
the "nodelay" option on line 2 of /etc/pam.d/system-auth):

[root@redhat pam.d]# pwd
/etc/pam.d
[root@redhat pam.d]# cat sshd
#%PAM-1.0
auth       required     /lib/security/pam_stack.so service=system-auth
auth       required     /lib/security/pam_nologin.so
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_limits.so
session    optional     /lib/security/pam_console.so
[root@redhat pam.d]# cat system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_unix.so likeauth nullok nodelay
auth        required      /lib/security/pam_deny.so

account     required      /lib/security/pam_unix.so

password    required      /lib/security/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so

5. Proof Of Concept.

The @ Mediaservice.net D.S.D. (Data Security Division) has developed a working
proof of concept that automatically exploits this information leak issue. The
source code is available for free download at:

http://lab.mediaservice.net/code/ssh_brute.c
http://lab.mediaservice.net/code/openssh-3.6.1p1_brute.diff

Copyright (c) 2003 @ Mediaservice.net Srl. All rights reserved. 

Version-Release number of selected component (if applicable):
openssh-server-3.1p1-6

How reproducible:
Always

Steps to Reproduce:
1. ssh <validuser>@<redhat box>
2. type in an incorrect password
3. ssh <invaliduser>@<redhat box>
4. type in an incorrect password
    

Actual Results:  When the username is a valid one on the system there will be a
momentary pause (3-5 seconds) before the invalid password text is displayed, an
invlid user will not have the pause.

Additional info:
Comment 1 Philip Ross 2003-07-29 18:24:48 EDT
The errata packages (https://rhn.redhat.com/errata/RHSA-2003-222.html) released
to fix this issue have introduced a small side effect - /var/log/messages now
records an authentication failure for every successful login (happens on at
least RedHat 7.2 and 8.0):

Jul 29 23:17:26 redhat72 sshd(pam_unix)[10163]: authentication failure; logname=
uid=0 euid=0 tty=NODEVssh ruser= rhost=remotehost  user=root
Jul 29 23:17:31 redhat72 sshd(pam_unix)[10163]: session opened for user root by
(uid=0)

It would be preferable if the validation of the username was not actually logged
as an authentication failure as it makes it difficult to tell the difference
between successful logins and real authentication failures.
Comment 2 John Hodrien 2003-08-21 12:39:28 EDT
Agreed.  And without the nodelay option, you end up with an extra delay before
logging in.  I'd prefer to be able to have a fast login, and keep the delay if
there's a failed attempt.

Note You need to log in before you can comment on or make changes to this bug.