[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150723125816.13ED03321FC@smtpvbsrv1.mitre.org>
Date: Thu, 23 Jul 2015 08:58:16 -0400 (EDT)
From: cve-assign@...re.org
To: mancha1@...o.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, isowarez.isowarez.isowarez@...glemail.com, djm@...drot.org
Subject: Re: CVE Request for OpenSSH vulnerability - authentication limits bypass
-----BEGIN PGP SIGNED MESSAGE-----
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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVsOQKAAoJEKllVAevmvmsdPEH/iDAntsGjUOC44KyKBJlewLW
K1Biykxtha0x3SK9GsM9bLBx+nO0fNJHKk2z5BUY7TxiDF9hGYcbD20XAmhgl80g
fWBai2bOY9zIv+oL6nDajDJznQGxvoyQsD/V8UbA/dVWOA45i7Xeg8U5CPnQl7Rf
VLHjd57U4+pyctAKe4jQ1lneQZoG8QQLnh20VVMBbxIWVDMk0m6sVIGiQIgXdSCM
19+67xU4MDcSGiV/ya32nArRr4csDkQMfCbzkuT4nQ4BQl/hATTKhz6dSRAScBZT
grPv0CFvFAsX1PiTNBms7zi0tXWRYxQzHVU0hZxbf1SjL0jkfYuCwGfOwJZP7mQ=
=ZK9C
-----END PGP SIGNATURE-----
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.
