Date: Thu, 23 Jul 2015 11:41:01 +0000 From: mancha <mancha1@...o.com> To: oss-security@...ts.openwall.com Cc: isowarez.isowarez.isowarez@...glemail.com, cve-assign@...re.org, djm@...drot.org Subject: Re: Re: CVE Request for OpenSSH vulnerability - authentication limits bypass MITRE et al. - I don't think I agree with your CVE-2015-5600 assignation analysis. The change introduced by upstream's patch  is not to prevent a client from supplying an arbitrary number of keyboard-interactive devices, per se. What the fix does is prevent a given keyboard-interactive device from getting queried more than once per userauth request. Unfortunately I don't have ready access to a server with multiple keyboard-interactive device types but, unless I'm mistaken, if the devices in the supplied client list all differ, the behavior is unchanged pre and post patch: -oKbdInteractiveDevices="snap,crackle,pop" The difference in behavior can be observed when the list contains repeats: -oKbdInteractiveDevices="snap,snap,snap" Pre-patch the above would query the snap device three times per userauth request while post-patch only once. So, your hypothetical of: -oKbdInteractiveDevices="krb5,krb6,krb7,krb8,krb9,krb10,krb11" would work the same before and after the fix. Each of the seven listed devices would get queried once per userauth request. Assuming a default maxauth of 6, that means a total of 42 device queries before the connection gets severed. In practice, the flaw allows mounting a brute-force attack using fewer connections. For example, if a server has MaxAuthTries=6, one can use: -oKbdInteractiveDevices="pam,pam,pam" to pack 18 password guesses (three per userauth request) in a single connection instead of the intended limit of 6. The fix prevents this circumvention of MaxAuthTries. Please let me know if you don't agree. --mancha  https://marc.info/?l=oss-security&m=143760646430682&w=2 On Thu, Jul 23, 2015 at 12:27:17AM -0400, cve-assign@...re.org wrote: > As far as we can tell, the essence of the vulnerability is that the > client shouldn't be able to specify an arbitrarily large number of > KbdInteractiveDevices and be entitled to have the server cooperate. > Use CVE-2015-5600. > > Here are additional notes in case anyone was expecting two CVE IDs. > > The patch at: > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/auth2-chall.c > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/auth2-chall.c.diff?r1=1.42&r2=1.43&f=h > > seems to suggest a very similar decision. With this change, the server > no longer cooperates even with: > > -oKbdInteractiveDevices=pam,pam > > and this makes sense because, if a client is behaving normally, using > pam a second time would typically just waste server resources, and > would not increase usability from the client's perspective. The only > exception we've thought of is a server that sometimes makes > false-negative access-control decisions, e.g., either it is > intentionally designed to be inconsistent, or uses an intermittently > available hardware authentication device. In the latter case, maybe > users were actually supposed to do something like: > > -oKbdInteractiveDevices=iahad,iahad,iahad > > and the patch would have to be revised to support that. > > More importantly, we don't think the issue should be characterized as > a "MaxAuthTries bypass." If there are several different > keyboard-interactive methods supported by the server, and there's a > use case in which the client user can type in a single string and have > the client program attempt all of the keyboard-interactive methods, > then the server arguably shouldn't block any if MaxAuthTries is > reached. From the perspective of the client user, it's only one try. > > Example: MaxAuthTries has its default value of six, but MIT-KIT has > suddenly released six new major Kerberos protocol versions, and the > legitimate user enters: > > -oKbdInteractiveDevices=krb5,krb6,krb7,krb8,krb9,krb10,krb11 > > We don't think it's necessarily correct to block use of the krb11 > protocol because it's the seventh one. > > This might not be a completely valid example. The essential point is > that we don't feel there's a remaining vulnerability in which a > MaxAuthTries value of N is supposed to prevent a command line with N+1 > different supported elements in the KbdInteractiveDevices list. There > is no CVE ID tied directly to the concept of a MaxAuthTries bypass. > > -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 > Burlington Road, Bedford, MA 01730 USA [ PGP key available through > http://cve.mitre.org/cve/request_id.html ] Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ