Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Jul 2015 08:58:16 -0400 (EDT)
Subject: Re: CVE Request for OpenSSH vulnerability - authentication limits bypass

Hash: SHA1

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.

> 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.

> 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.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ