[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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 [1] 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
[1] 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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
