Bug 1245969 (CVE-2015-5600) - CVE-2015-5600 openssh: MaxAuthTries limit bypass via duplicates in KbdInteractiveDevices
Summary: CVE-2015-5600 openssh: MaxAuthTries limit bypass via duplicates in KbdInterac...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2015-5600
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1245971 1246521 1281468 1318182
Blocks: 1210268 1244676
TreeView+ depends on / blocked
 
Reported: 2015-07-23 08:47 UTC by Martin Prpič
Modified: 2019-10-10 09:59 UTC (History)
18 users (show)

Fixed In Version: openssh 7.0
Doc Type: Bug Fix
Doc Text:
It was discovered that the OpenSSH sshd daemon did not check the list of keyboard-interactive authentication methods for duplicates. A remote attacker could use this flaw to bypass the MaxAuthTries limit, making it easier to perform password guessing attacks.
Clone Of:
Environment:
Last Closed: 2016-03-21 21:04:46 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:2088 normal SHIPPED_LIVE Moderate: openssh security, bug fix, and enhancement update 2015-11-19 08:38:51 UTC
Red Hat Knowledge Base (Solution) 1580743 None None None Never
Red Hat Product Errata RHSA-2016:0466 normal SHIPPED_LIVE Moderate: openssh security update 2016-03-22 00:18:13 UTC

Description Martin Prpič 2015-07-23 08:47:48 UTC
It was found that OpenSSH would allow an attacker to request a large number of keyboard-interactive devices when entering a password, which could allow a remote attacker to bypass the MaxAuthTries limit defined in the sshd_config file.

This flaw only affects OpenSSH configurations that have the 'KbdInteractiveAuthentication' configuration option set to 'yes'. By default, this option has the same value as the 'ChallengeResponseAuthentication' option.

By default, all versions of Red Hat Enterprise Linux have the 'ChallengeResponseAuthentication' option set to 'no', meaning default OpenSSH configurations are not affected by this flaw.

Upstream patch:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/auth2-chall.c.diff?r1=1.42&r2=1.43&f=h

CVE assignment:

http://seclists.org/oss-sec/2015/q3/173

External References:

https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/

Comment 1 Martin Prpič 2015-07-23 08:48:22 UTC
Created openssh tracking bugs for this issue:

Affects: fedora-all [bug 1245971]

Comment 4 Tomas Hoger 2015-07-24 13:43:51 UTC
As noted in comment 0 above, this issue does not affect the default OpenSSH sshd configuration in Red Hat Enterprise Linux 4, 5, 6, and 7, because the default sshd_config (/etc/ssh/sshd_config) explicitly disables ChallengeResponseAuthentication using "ChallengeResponseAuthentication no".  Only configurations with "ChallengeResponseAuthentication yes" are affected by this issues.  Note that the lack of the ChallengeResponseAuthentication configuration directive in sshd_config does not imply that the ChallengeResponseAuthentication is disabled, as its default value is "yes".

This issue affects keyboard-interactive authentication method.  One simple way to check if a system may be affected by this issue is to connect to it using ssh client running in verbose mode and check if keyboard-interactive is listed among authentication methods that server offered.  For example, run:

  $ ssh -v test@127.0.0.1

In the generated debug output, search for line as:

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

or

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive

If the list does not include "keyboard-interactive", it is not affected by this issue because of its configuration.  Systems with keyboard-interactive method enabled may be affected.

The default PAM configuration also mitigates impact of this flaw, as pam_unix is configured to add 2 second delay after unsuccessful authentication.  This limits the number of password prompts displayed before LoginGraceTime (the default value is 120 seconds) is reached.  I.e. no more than 60 password guesses per connection should be expected rather than thousands mentioned in the report for FreeBSD.

This issue can be mitigated by disabling ChallengeResponseAuthentication in the sshd_config configuration file and restarting the sshd service.

The impact of this issue is limited to increasing efficiency of the brute-force password guessing attacks.

Given the limited impact on Red Hat Enterprise Linux and the fact that default configuration is not affected, this is not planned to be fixed immediately, but may be corrected in future OpenSSH updates in Red Hat Enterprise Linux 6 and 7.  This issue is not planned to be corrected in Red Hat Enterprise Linux 5 and earlier.

Mitigation:

This issue can be mitigated by disabling keyboard-interactive authentication method.  That can be achieved by setting "ChallengeResponseAuthentication no" in the /etc/ssh/sshd_config configuration file and restarting the sshd service.

Statement:

This issue does not affect the default OpenSSH sshd configuration in Red Hat Enterprise Linux 4, 5, 6 and 7.

Comment 7 Fedora Update System 2015-07-30 13:56:18 UTC
openssh-6.9p1-3.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Tomas Hoger 2015-08-13 06:52:11 UTC
This issue was fixed upstream in OpenSSH 7.0:

http://www.openssh.com/txt/release-7.0

Comment 9 Fedora Update System 2015-08-27 23:48:59 UTC
openssh-6.6.1p1-16.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.

Comment 18 errata-xmlrpc 2015-11-19 08:04:54 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2015:2088 https://rhn.redhat.com/errata/RHSA-2015-2088.html

Comment 20 Dimitri 2016-01-14 05:10:52 UTC
Nice that this was fixed in RHEL7. 

What is the status of the fix for RHEL6 - and why not fix for RHEL5?

Comment 22 errata-xmlrpc 2016-03-21 20:18:26 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2016:0466 https://rhn.redhat.com/errata/RHSA-2016-0466.html


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