Bug 995168 - (BREACH, CVE-2013-3587) CVE-2013-3587 BREACH attack against HTTP compression
CVE-2013-3587 BREACH attack against HTTP compression
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20130802,repor...
: Security
: 994856 (view as bug list)
Depends On:
Blocks: 994861
  Show dependency treegraph
 
Reported: 2013-08-08 13:22 EDT by Vincent Danen
Modified: 2016-03-09 09:33 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-08 01:14:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2013-08-08 13:22:35 EDT
Angelo Prado, Neal Harris and Yoel Gluck reported [1],[2] that SSL/TLS attacks are still viable via a "BREACH" (Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext) attack, which they describe as:

While CRIME was mitigated by disabling TLS/SPDY compression (and by modifying gzip to allow for explicit separation of compression contexts in SPDY), BREACH attacks HTTP responses. These are compressed using the common HTTP compression, which is much more common than TLS-level compression. This allows essentially the same attack demonstrated by Duong and Rizzo, but without relying on TLS-level compression (as they anticipated).

BREACH is a category of vulnerabilities and not a specific instance affecting a specific piece of software. To be vulnerable, a web application must:

* Be served from a server that uses HTTP-level compression
* Reflect user-input in HTTP response bodies
* Reflect a secret (such as a CSRF token) in HTTP response bodies

It is important to note that the attack is agnostic to the version of TLS/SSL, and does not require TLS-layer compression. Additionally, the attack works against any cipher suite. Against a stream cipher, the attack is simpler; the difference in sizes across response bodies is much more granular in this case. If a block cipher is used, additional work must be done to align the output to the cipher text blocks.


CERT has an entry describing the flaw as well [3].  Currently no CVE is assigned as MITRE is attempting to determine whether one CVE will suffice, or whether it will require multiple CVEs (one per affected product). [4]

Mitigations are noted by the researchers as follows

1. Disable HTTP compression.
2. Separate the secrets from the user input.
3. Randomize the secrets in each client request.
4. Mask secrets (effectively randomizing by XORing with a random secret per request).
5. Protect web pages from CSRF attacks.
6. Obfuscate the length of web responses by adding random amounts of arbitrary bytes.


[1] http://breachattack.com/
[2] http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf
[3] http://www.kb.cert.org/vuls/id/987798
[4] http://www.openwall.com/lists/oss-security/2013/08/07/1
Comment 1 Vincent Danen 2013-08-08 13:24:29 EDT
Sorry, just realized that CERT did indeed reference CVE-2013-3587.
Comment 2 Vincent Danen 2013-08-08 15:05:15 EDT
This is more related to compression than SSL itself, from my understanding.  As noted in Novell's bug report [1] we need to look at mod_deflate, probably mod_gzip, and Accept-* headers in case PHP is doing output compression (the same would likely go for other languages).

[1] https://bugzilla.novell.com/show_bug.cgi?id=833754
Comment 3 Vincent Danen 2013-08-08 15:08:12 EDT
*** Bug 994856 has been marked as a duplicate of this bug. ***
Comment 5 Huzaifa S. Sidhpurwala 2014-01-07 23:08:53 EST
While there has been some discussion about addressing this flaw in upstream Apache project, no decision was reached. It is currently unlikely that this issue will be fixed at server level. Discussion here:

http://www.mail-archive.com/dev@httpd.apache.org/msg57592.html

The version of httpd package shipped with Red Hat Enterprise Linux 5 and 6 is not vulnerable by default, because 'DEFLATE' is not enabled in its default configuration.

The simplest mitigation is to disable DEFLATE for responses which are vulnerable to this attack. Other mitigation options are listed in comment #0
Comment 6 Huzaifa S. Sidhpurwala 2014-01-07 23:16:01 EST
Statement:

This issue is not planned to be addressed in the version of httpd as shipped with Red Hat Enterprise Linux 5 and 6. More details and possible mitigations are mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=995168#c5
Comment 7 Huzaifa S. Sidhpurwala 2014-01-08 01:14:35 EST
This issue affects the version of httpd package as shipped with Fedora 19 and Fedora 20. The version of httpd package shipped with Fedora is not vulnerable by default, because 'DEFLATE' is not enabled in its default configuration. Users are advised to follow mitigation details listed in comment #0

Note You need to log in before you can comment on or make changes to this bug.