Hello, any version of openssh with default config is vulnerable to MaxAuthTries bypass attack[1]. Exploit is available at [1] 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. [1] https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/
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
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.
See also the posts by mancha and cve-assign here: http://seclists.org/oss-sec/2015/q3/156.
This discussion on openbsd-misc may also be of interest: http://marc.info/?t=143766048000005&r=1&w=2.
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
Over two months now, is that enough backing? Are we ready to go stable.
openssh-7.1_p1-r2 should be fine to go stable now
amd64 stable
x86 stable
ppc stable
sparc stable
arm stable
Stable for HPPA PPC64.
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 ?
(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 )
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? =)
(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.
(In reply to SpanKY from comment #17) http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1a979a16ac75fda780da5dfd3d31ab8a2b4acfec
alpha stable (last arch)
(In reply to Matt Turner from comment #19) > alpha stable > > (last arch) Thank you arches, @maintainers: please cleanup vulnerable versions New GLSA request filed
Maintainer(s), please drop the vulnerable version(s).
This issue was resolved and addressed in GLSA 201512-04 at https://security.gentoo.org/glsa/201512-04 by GLSA coordinator Yury German (BlueKnight).
Re-Opening for cleanup. Maintainer(s), please drop the vulnerable version(s).
Setting dependency to Bug #571892 for cleanup.
Cleanup complete.