|Summary:||<net-misc/openssh-7.1_p1-r2: MaxAuthTries bypass attack Vulnerability (CVE-2015-5600)|
|Product:||Gentoo Security||Reporter:||Andrew Savchenko <bircoph>|
|Component:||Default Configs||Assignee:||Gentoo Security <security>|
|Severity:||normal||CC:||base-system, info, kfm, mjo|
|Whiteboard:||A3 [glsa cve]|
|Package list:||Runtime testing required:||---|
|Bug Depends on:||571892|
Description Andrew Savchenko 2015-07-20 22:31:02 UTC
Hello, any version of openssh with default config is vulnerable to MaxAuthTries bypass attack. Exploit is available at  as well. Default options (from man sshd_config are): ChallengeResponseAuthentication yes KbdInteractiveAuthentication yes UsePAM no Please note, that in order to use exploit UsePAM should be set to "yes", but this is not the only way to exploit reported vulnerability. IMO vulnerability is not severe, as it may hurt only weak passwords. Anyway it should be taken with care and handled somehow.  https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/
Comment 1 Kerin Millar 2015-07-24 23:17:07 UTC
Assigned as CVE-2015-5600. There is some useful commentary in Red Hat's bug tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1245969#c4 As pointed out there, the principal issue is with keyboard-interactive authentication, as facilitated by ChallengeResponseAuthentication being enabled. While PAM based authentication is also impacted upon, it is to a lesser extent due to the pam_unix module enforcing its own delay. Here is the 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
Comment 2 Kerin Millar 2015-07-24 23:36:14 UTC
Created attachment 407558 [details, diff] openssl-6_9p1_kbd-interactive.diff Patch to prevent the server from co-operating with a client specifying an arbitrarily large number of KbdInteractiveDevices.
Comment 3 Kerin Millar 2015-07-24 23:47:02 UTC
See also the posts by mancha and cve-assign here: http://seclists.org/oss-sec/2015/q3/156.
Comment 4 Torbjörn Lönnemark 2015-07-25 18:59:17 UTC
This discussion on openbsd-misc may also be of interest: http://marc.info/?t=143766048000005&r=1&w=2.
Comment 5 SpanKY 2015-08-12 08:09:47 UTC
it's in the tree now, but lacks USE=X509 support. upstream is usually pretty fast there so we can wait a little bit (should anyways to let it bake a bit). http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b94b01110ca2fb427c039751c0b43cdc8dfd7bb6
Comment 6 Yury German 2015-11-03 14:23:54 UTC
Over two months now, is that enough backing? Are we ready to go stable.
Comment 7 SpanKY 2015-11-03 16:01:54 UTC
openssh-7.1_p1-r2 should be fine to go stable now
Comment 8 Agostino Sarubbo 2015-11-03 17:12:56 UTC
Comment 9 Agostino Sarubbo 2015-11-03 17:14:06 UTC
Comment 10 Agostino Sarubbo 2015-11-04 14:27:39 UTC
Comment 11 Agostino Sarubbo 2015-11-05 11:00:24 UTC
Comment 12 Markus Meier 2015-11-05 20:57:25 UTC
Comment 13 Jeroen Roovers 2015-11-06 04:21:49 UTC
Stable for HPPA PPC64.
Comment 14 Benny Pedersen 2015-11-09 21:50:32 UTC
root logins is not working with this one here, with default configs, in 6.9 it was possible to login with root and default, so here i think 7.1 have incompatible changes what are considered stable in this ebuild as now ?
Comment 15 Kristian Fiskerstrand 2015-11-09 22:02:51 UTC
(In reply to Benny Pedersen from comment #14) > root logins is not working with this one here, with default configs, in 6.9 > it was possible to login with root and default, so here i think 7.1 have > incompatible changes > > what are considered stable in this ebuild as now ? Please file a separate bug for issues not related to this security bug report (although that might be related to https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html )
Comment 16 Michael Orlitzky 2015-11-10 01:31:06 UTC
Benny's comment is referring to the new default for PermitRootLogin. From the 7.0 release notes: * The default for the sshd_config(5) PermitRootLogin option has changed from "yes" to "prohibit-password". For stable users (server operators, at least) there's a good chance they're going to lose remote access. Guess how I got looking for this bug? =)
Comment 17 SpanKY 2015-11-10 04:42:09 UTC
(In reply to Michael Orlitzky from comment #16) odd, the default config has long implied it was set to "no", not "yes". but clearly the commented config doesn't match the code. i'll update the log in the ebuild to note this.
Comment 18 SpanKY 2015-11-10 04:57:48 UTC
(In reply to SpanKY from comment #17) http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1a979a16ac75fda780da5dfd3d31ab8a2b4acfec
Comment 19 Matt Turner 2015-11-15 18:28:06 UTC
alpha stable (last arch)
Comment 20 Kristian Fiskerstrand 2015-11-15 18:33:20 UTC
(In reply to Matt Turner from comment #19) > alpha stable > > (last arch) Thank you arches, @maintainers: please cleanup vulnerable versions New GLSA request filed
Comment 21 Yury German 2015-11-28 16:53:54 UTC
Maintainer(s), please drop the vulnerable version(s).
Comment 22 GLSAMaker/CVETool Bot 2015-12-21 14:23:39 UTC
This issue was resolved and addressed in GLSA 201512-04 at https://security.gentoo.org/glsa/201512-04 by GLSA coordinator Yury German (BlueKnight).
Comment 23 Yury German 2015-12-21 14:25:10 UTC
Re-Opening for cleanup. Maintainer(s), please drop the vulnerable version(s).
Comment 25 Aaron Bauman 2016-06-12 00:38:07 UTC