Bug 1357442 (CVE-2016-6210) - CVE-2016-6210 openssh: User enumeration via covert timing channel
Summary: CVE-2016-6210 openssh: User enumeration via covert timing channel
Status: NEW
Alias: CVE-2016-6210
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20160714,repor...
Keywords: Reopened, Security
Depends On: 1357443 1446513 1477683 1477684
Blocks: 1357444 1415638
TreeView+ depends on / blocked
 
Reported: 2016-07-18 08:50 UTC by Adam Mariš
Modified: 2018-10-19 14:02 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A covert timing channel flaw was found in the way OpenSSH handled authentication of non-existent users. A remote unauthenticated attacker could possibly use this flaw to determine valid user names by measuring the timing of server responses.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-21 08:12:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2029 normal SHIPPED_LIVE Moderate: openssh security, bug fix, and enhancement update 2017-08-01 18:11:55 UTC
Red Hat Product Errata RHSA-2017:2563 normal SHIPPED_LIVE Moderate: openssh security update 2017-08-31 19:23:55 UTC

Description Adam Mariš 2016-07-18 08:50:42 UTC
When SSHD tries to authenticate a non-existing user, it will pick up a fake password structure hardcoded in the SSHD source code. On this hard coded  password  structure  the password hash is based on BLOWFISH ($2) algorithm. If real users passwords are hashed using SHA256/SHA512, then sending large passwords (10KB)  will result in shorter response time from the server for non-existing users. This allows remote attacker to enumerate existing users on system logging via SSHD.

Published in:

http://seclists.org/fulldisclosure/2016/Jul/51

Comment 1 Adam Mariš 2016-07-18 08:51:09 UTC
Created openssh tracking bugs for this issue:

Affects: fedora-all [bug 1357443]

Comment 5 Dhiru Kholia 2016-07-20 05:25:16 UTC
OpenSSH in RHEL 6, 7 uses a helper binary "unix_chkpwd" (via the pam_unix module) to verify the passwords. Even when long passwords are passed to OpenSSH, they are truncated to 512 bytes when passed to the helper binary. Hence, RHEL 6 and 7 are not affected by this timing attack which utilizes very long passwords.

$ tail -f /var/log/secure
...
Jul 21 09:49:44 localhost unix_chkpwd[2810]: password check failed for user (test)
Jul 21 09:49:44 localhost sshd[2808]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=gateway  user=test

To obtain above logs, turn on "audit" flag for pam_unix.so module in /etc/pam.d/system-auth and /etc/pam.d/password-auth files (see "man pam_unix").

Relevant files:

Linux-PAM-1.1.8/modules/pam_unix/unix_chkpwd.c
Linux-PAM-1.1.8/modules/pam_unix/pam_unix_acct.c
Linux-PAM-1.1.8/modules/pam_unix/support.c (_unix_verify_password, _unix_run_helper_binary)
Linux-PAM-1.1.8/modules/pam_unix/passverify.c (get_pwd_hash, get_account_info)
openssh-6.6p1/auth-pam.c

https://www.trustwave.com/Resources/SpiderLabs-Blog/Username-Enumeration-against-OpenSSH-SELinux-with-CVE-2015-3238/ is also a relevant read.

OpenSSH under RHEL 5 does not use the helper binary "unix_chkpwd" and it does the password verification itself (in the sshd process). OpenSSH under RHEL 5 triggers high CPU usage when processing very long passwords. However, RHEL uses the faster (50x) md5crypt instead of sha256crypt/sha512crypt for hashing passwords. Hence, the delay generated by processing very long passwords is quite small (compared to sha512crypt) and barely noticeable over the network. I am marking rhel-5/openssh as affected but it would be hard to exploit this in practice. 

OpenSSH under Ubuntu uses PAM but does not use the "unix_chkpwd" helper binary, hence the long passwords are not truncated automatically. The CPU consumption of sshd reaches 100% for multiple seconds when handling a password of 25000 characters. Due to these reasons, Ubuntu 16.04 LTS is vulnerable to this user enumeration attack.

$ gdb --args /usr/sbin/sshd -D -d  # this can be used for debugging sshd

Under Ubuntu, the above gdb session will hit a breakpoint on "crypt_r" function (which does password hashing) which further confirms that the helper binary "unix_chkpwd" is not used under Ubuntu.

Update (26-April-2017): Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 ship with SELinux enabled by default. However, the helper binary "unix_chkpwd" (the usage of which mitigates this flaw) is not used when SELinux is disabled. Disabling SELinux exposes the OpenSSH software to this flaw.

Comment 6 Fedora Update System 2016-07-20 17:48:32 UTC
openssh-7.2p2-10.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 8 Dhiru Kholia 2017-04-26 07:17:59 UTC
Statement:

This issue in OpenSSH is mitigated by the usage of SELinux in Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7.

Comment 10 errata-xmlrpc 2017-08-01 18:45:08 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2017:2029 https://access.redhat.com/errata/RHSA-2017:2029

Comment 15 errata-xmlrpc 2017-08-31 15:24:30 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2017:2563 https://access.redhat.com/errata/RHSA-2017:2563

Comment 16 John Haxby 2018-10-19 14:02:25 UTC
I haven't looked into why or how, but the fix does not work on CentOS6 (I don't have a RHEL6 available to check, but I assume it's the as it's the same RPM and everything).

Using https://www.exploit-db.com/exploits/40136/ I can consistently discover users with passwords once I'd disabled selinux.


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