Re: Re: CVE Request for OpenSSH vulnerability - authentication limits bypass

[mancha <mancha1 () zoho com>]

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 () mitre 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 ]

Attachment: _bin
Description: