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

[mancha <mancha1 () zoho com>]

On Thu, Jul 23, 2015 at 08:58:16AM -0400, cve-assign () mitre org wrote:
> Our message was written from the perspective that everyone already
> understood what the patch does, and to start from there in defining
> what CVE-2015-5600 means.

The patch is relatively un-intrusive in terms of LoC but understanding
its impact requires knowledge of how OpenSSH implements
keyboard-interactive authentication. That's probably too esoteric for
one to readily assume "everyone already understands" it.  
> > if the devices in the supplied client list all differ, the behavior
> > is unchanged pre and post patch:
>
> Yes; however, because no server supports an arbitrarily large number
> of different KbdInteractiveDevices, a client that wishes to launch an
> effective attack with an arbitrarily large number must use
> duplication, as in the original example with 10000 instances of the
> pam device. Disallowing all duplication is one way to prevent this
> specific "arbitrarily large number" scenario. As we suggested in the
> iahad example, disallowing all duplication might break somebody's use
> case. (This is just theoretical; we haven't heard any reports of a
> problem.) Even if the patch is revised to allow a small amount of
> duplication, the definition of CVE-2015-5600 will stay the same.

You make a compelling defense for your description of CVE-2015-5600. And
as you say, as worded it would cover the case of a future OpenSSH
modified to accommodate your iahad hypothetical.

Nonetheless, "arbitrarily large" isn't possible (cf. SSHBUF_SIZE_MAX and
such) yet the duplication problem remains (it isn't reasonable for a
user to expect that MaxAuthTries=6 allows 1000 password attempts).

A crisper and more accurate description of the current issue (sans
hypotheticals) is the ability to trigger multiple queries to a given
keyboard-interactive device within a single userauth request by having
duplication in the device list.

> > 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.
>
> Yes; "the client shouldn't be able to specify an arbitrarily large
> number of KbdInteractiveDevices and be entitled to have the server
> cooperate" means that the vulnerable behavior was the server's
> decision to cooperate with the client and execute a piece of code 3
> times (or, more importantly, 10000 times), when a more reasonable
> behavior is to execute that piece of code 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.
>
> What we are saying is that we don't consider that specific behavior,
> after the fix, to be a separate vulnerability that requires a separate
> CVE ID. It is possible for someone to make an argument that the "42
> device queries" behavior is inconsistent with the documentation and
> that the connection must be severed after 6 device queries. Although
> we currently don't agree with that argument, we consider the argument
> somewhat reasonable. That's why we chose to explicitly mention the
> case of a legitimate list of seven devices, and provide our
> perspective on whether we would support a second CVE request based on
> a claim of an incomplete fix.

RFC 4256 leaves the interpretation of the submethod field of the
userauth request up to the server implementation. 

The right way to frame the question isn't whether there's a legitimate
use of 7 devices and 6 auth tries resulting in 42 total queries but what
MaxAuthTries is meant to restrict. If it isn't entirely clear from
documentation (and maybe it isn't) that it's a bound on userauth
requests then that is easy enough to fix in the manpage.

--mancha

Attachment: _bin
Description: