[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 24 Sep 2013 01:29:11 -0400 (EDT)
From: cve-assign@...re.org
To: kseifried@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: SSL BREACH
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>Date: Tue, 6 Aug 2013 20:11:53 -0400 (EDT)
>>I assume this will get handled like CVE-2009-3555?
>>
>>http://threatpost.com/breach-compression-attack-steals-https-secrets-in-under-30-seconds/101579
>>
>>http://it.slashdot.org/story/13/08/05/233216
>>
>>https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/
>
>MITRE has looked at this in some depth but has not yet decided whether
>this can be treated as a vulnerability in a protocol, with one CVE
>shared across every product. We do realize that
>http://www.kb.cert.org/vuls/id/987798 currently contains one CVE ID.
Our current thought is that BREACH is not a vulnerability in the HTTPS
protocol, and instead should be considered a vulnerability class. In
this view, there would be one CVE for each independent codebase that
can be successfully attacked using the BREACH exploit methodology.
As a vulnerability class, BREACH is somewhat similar to the XSS
vulnerability class. They are both about limitations on what a web
site can safely do with untrusted client input:
Reflected cross-site scripting (XSS) - your web site must
not take arbitrary markup strings from a client and include
them verbatim in an HTML document within an HTTP response
Cross-site duplicate compression (XSDC, aka BREACH) - your web
site (sometimes) must not take arbitrary strings from a
client and include them verbatim in the input to a compression
algorithm used for an HTTPS response
(This is just a way to outline why we think that the
one-CVE-per-codebase approach makes sense. It doesn't mean that MITRE
is necessarily in favor of adopting this "XSDC" terminology.)
MITRE is not currently seeing many reports in which the BREACH issue
is being associated with an affected codebase of a specific web
application. Maybe the only public example is the OWA codebase
mentioned in the original BREACH paper:
http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf
(Yes, we realize that BREACH exploitation, in general, depends both on
details of the web application and on details of the web-server
configuration. As a practical matter, the details of the web
application are very likely to be the limiting factor on the overall
population size of exploitable web sites.)
There are other reports indicating that other types of products can or
should be fixed because they contribute to the possibility of a
successful BREACH attack against a specific web application, but no
specific web application is identified, e.g.,
Open source:
https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/
https://github.com/rails/rails/pull/11729
Non-open source:
http://support.f5.com/kb/en-us/solutions/public/14000/600/sol14634.html
https://techzone.ergon.ch/breach_mitigation
There is nothing yet suggesting that a huge number of CVEs will
ultimately come out of this.
- --
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)
iQEcBAEBAgAGBQJSQSF4AAoJEKllVAevmvms5H0H/Ag4jMKPYCL20yUGi79TFG0R
g4Ec9byqY1nTdRFtni7X3Fj3hpZ65o8XTMK6QadZOlIyxxWew9COjuIhXBA3DGyE
eidVDWM23TMHV6i9B4Ksqz4JO1UfrNMx3HjREijxQ3PO4E8sxb0QODIHwashUYnb
ciw/Fj7b5dI9jTl6CTqfZfC4BT/HsbzjfnQKy4QHyOvq1AzoFFsQWCC+qnm3ixoM
1x8s5z9lJ5XP0JpvDIrVFZWyx+P7XP0Py8kQLrBSM9ogqOSMEays/pZUcUlA8wIr
sQWGt7NrBv/iPKMKXIaxp7NlkDnpAVgd5WTUCVfF86hGzCDQ70BuPSoS7iHsDE0=
=dn4Z
-----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.
