oss-sec mailing list archives
Re: Re: CVE Request for OpenSSH vulnerability - authentication limits bypass
From: mancha <mancha1 () zoho com>
Date: Thu, 23 Jul 2015 14:45:42 +0000
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:
Current thread:
- CVE Request for OpenSSH vulnerability - authentication limits bypass king cope (Jul 21)
- Re: CVE Request for OpenSSH vulnerability - authentication limits bypass Jason A. Donenfeld (Jul 22)
- Re: CVE Request for OpenSSH vulnerability - authentication limits bypass mancha (Jul 22)
- Re: CVE Request for OpenSSH vulnerability - authentication limits bypass cve-assign (Jul 22)
- Re: Re: CVE Request for OpenSSH vulnerability - authentication limits bypass mancha (Jul 23)
- Re: CVE Request for OpenSSH vulnerability - authentication limits bypass cve-assign (Jul 23)
- Re: Re: CVE Request for OpenSSH vulnerability - authentication limits bypass mancha (Jul 23)
- Re: Re: CVE Request for OpenSSH vulnerability - authentication limits bypass mancha (Jul 23)