Bug 995168 (BREACH, CVE-2013-3587)

Summary: CVE-2013-3587 BREACH attack against HTTP compression
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: huzaifas, jkaluza, jkurik, jorton, mrunge, pahan, webstack-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-08 06:14:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 994861    

Description Vincent Danen 2013-08-08 17:22:35 UTC
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 17:24:29 UTC
Sorry, just realized that CERT did indeed reference CVE-2013-3587.

Comment 2 Vincent Danen 2013-08-08 19:05:15 UTC
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 19:08:12 UTC
*** Bug 994856 has been marked as a duplicate of this bug. ***

Comment 5 Huzaifa S. Sidhpurwala 2014-01-08 04:08:53 UTC
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-08 04:16:01 UTC
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 06:14:35 UTC
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