Bug 857051 (CRIME, CVE-2012-4929) - CVE-2012-4929 SSL/TLS CRIME attack against HTTPS
Summary: CVE-2012-4929 SSL/TLS CRIME attack against HTTPS
Keywords:
Status: CLOSED ERRATA
Alias: CRIME, CVE-2012-4929
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 886173 911051 911052 911061 911063 920868 920869
Blocks: 855407
TreeView+ depends on / blocked
 
Reported: 2012-09-13 13:18 UTC by Tomas Hoger
Modified: 2019-09-29 12:55 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-19 16:21:39 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Apache Bugzilla 53219 0 None None None 2019-06-28 11:02:43 UTC
Novell 779952 0 None None None 2019-06-28 11:02:43 UTC
Red Hat Product Errata RHSA-2013:0587 0 normal SHIPPED_LIVE Moderate: openssl security update 2013-03-05 02:11:42 UTC
Red Hat Product Errata RHSA-2013:0636 0 normal SHIPPED_LIVE Important: rhev-hypervisor6 security and bug fix update 2013-03-13 18:47:11 UTC
Red Hat Product Errata RHSA-2014:0416 0 normal SHIPPED_LIVE Important: rhevm-spice-client security update 2014-04-17 16:23:34 UTC

Description Tomas Hoger 2012-09-13 13:18:13 UTC
Juliano Rizzo and Thai Duong, researches that reported BEAST (Browser Exploit Against SSL/TLS, bug #737506) attack announced they are planning to disclose another attack against SSL/TLS named CRIME. The issue is planned to be presented by them on the ekoparty 2012 conference.

http://www.ekoparty.org/2012/juliano-rizzo.php
http://www.ekoparty.org/2012/thai-duong.php
http://www.h-online.com/security/news/item/BEAST-creators-develop-new-SSL-attack-1702136.html
http://threatpost.com/en_us/blogs/new-attack-uses-ssltls-information-leak-hijack-https-sessions-090512

Comment 1 Tomas Hoger 2012-09-13 13:38:02 UTC
After the announcement of the upcoming presentation of CRIME, researches started to investigate what the issue used by CRIME may be, resulting in publication attack taking advantage of information leak resulting from the use of compression in the SSL/TLS, such as following write-up from Thomas Pornin:

http://security.blogoverflow.com/2012/09/how-can-you-protect-yourself-from-crime-beasts-successor/

Several additional resources now confirm that the CRIME attack is the same as the problem identified by Thomas Pornin, and explain the meaning of CRIME abbreviation as "Compression Ratio Info-leak Made Easy":

http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/
http://www.youtube.com/watch?v=gGPhHYyg9r4
http://thread.gmane.org/gmane.network.gnutls.general/2887

In addition to zlib/deflate compression used by SSL/TLS, another attack vector using SPDY protocol with compression over non-compressed SSL/TLS connection is mentioned.

Also the following research paper form 2002 was pointed out, which discusses similar problems in the use of compression in SSL/TLS:

http://www.iacr.org/cryptodb/data/paper.php?pubkey=3091

Comment 2 Vincent Danen 2012-09-13 18:17:51 UTC
GNUTLS-SA-2012-4 notes the CRIME attack:

http://www.gnu.org/software/gnutls/security.html

and indicates that GnuTLS does not enable compression by default.  It also indicates that if compression is enabled, use the CBC ciphers which, while not mitigating the attack, make it substantially harder to succeed.

Comment 4 Tomas Hoger 2012-09-14 12:08:12 UTC
Red Hat Enterprise Linux 5 and 6 currently contain Mozilla Firefox version 10.0.x ESR.  Those versions:

- do not request the use of zlib compression in the SSL/TLS protocol
- do not support SPDY protocol

Therefore, they are not affected by either of the published attack vectors.

The support for SPDY protocol was added upstream in Firefox version 11, and only enabled by default in version 13.  Version 15 disables SPDY protocol compression.

http://www.mozilla.org/en-US/firefox/11.0/releasenotes/
https://hacks.mozilla.org/2012/02/spdy-brings-responsive-and-scalable-transport-to-firefox-11/
http://www.mozilla.org/en-US/firefox/13.0/releasenotes/

Comment 5 Tomas Hoger 2012-09-14 12:53:39 UTC
OpenSSL enables zlib compression by default for both clients and servers starting with version 0.9.8:

http://cvs.openssl.org/chngview?cn=9594

The openssl packages in Red Hat Enterprise Linux 5 (starting with RHBA-2009:0181 update released in Red Hat Enterprise Linux 5.3) and 6, and also in Fedora, contain a patch that makes the library check if OPENSSL_NO_DEFAULT_ZLIB environment variable is set (can have arbitrary value, even empty string) and disable the default zlib support.

http://pkgs.fedoraproject.org/cgit/openssl.git/tree/openssl-0.9.8j-env-nozlib.patch?id=1d20b5f2

Setting the OPENSSL_NO_DEFAULT_ZLIB environment variable before starting a client or a server application using OpenSSL can be used to disable zlib compression support and hence mitigate this flaw.  For example, httpd with mod_ssl has compression enabled by default in Red Hat Enterprise Linux 5 and 6, and hence it is used when client also supports it.  Adding the following line to the /etc/sysconfig/httpd file:

  export OPENSSL_NO_DEFAULT_ZLIB=1

and restarting the httpd service disables the use of SSL/TLS compression in mod_ssl and the compression will not be negotiated even when connecting client supports it.  Note that this environment variable only affects the use of SSL/TLS protocol compression and does not affect the use of HTTP protocol compression implemented by the mod_deflate module.

The openssl packages in Red Hat Enterprise Linux 3 and 4 are based on upstream version 0.9.7a and do not enable SSL/TLS zlib compression.

Comment 7 Tomas Hoger 2012-09-14 14:01:15 UTC
Network Security Services (NSS) library, also used by Mozilla Firefox, does not enable zlib compression by default.  The use of httpd with mod_nss on Red Hat Enterprise Linux 5 and 6 is not affected by this issue.

Comment 8 Vincent Danen 2012-09-14 20:42:34 UTC
Another interesting writeup:

http://bridge.grumpy-troll.org/2012/09/tls-crime-beast-and-you-programmer.html

Comment 9 Tomas Hoger 2012-09-16 16:54:25 UTC
Following CVE ids were assigned to this issue:

CVE-2012-4929 - for the SSL/TLS zlib/deflate attack variant
CVE-2012-4930 - the the SPDY over SSL/TLS connection without compression, now tracked via separate bug 857737

Comment 10 Huzaifa S. Sidhpurwala 2012-09-24 06:53:21 UTC
Mozilla assigned CVE-2012-3977 to the SPDY flaw in Firefox and Seamonkey.  The CVE is being tracked via the bug #859827.

Comment 11 Markus Falb 2012-09-24 11:09:25 UTC
(In reply to comment #5)
...
> Adding the following line to the /etc/sysconfig/httpd file:
> 
>   export OPENSSL_NO_DEFAULT_ZLIB=1

But there are other services but http that use ssl and are vulnerable?
Where to set this environment variable system wide?

Comment 12 Tomas Mraz 2012-09-24 11:32:48 UTC
There is no definitive place where to set environment variables system wide. The reason is that various services clean up their environment variable list when executing other binaries. For example the environment variables are reset when login process is running the user's shell on login.

Comment 14 Jan Lieskovsky 2012-10-17 13:19:56 UTC
Apache httpd web server mod_ssl module upstream bug:
  https://issues.apache.org/bugzilla/show_bug.cgi?id=53219

Relevant commits to disable TLS-level compression:
http://svn.apache.org/viewvc?view=revision&revision=1345319 (against trunk)
http://svn.apache.org/viewvc?view=revision&revision=1369585 (against 2.4.x branch)

Comment 15 Tomas Hoger 2012-10-17 14:21:16 UTC
(In reply to comment #14)
> Apache httpd web server mod_ssl module upstream bug:
>   https://issues.apache.org/bugzilla/show_bug.cgi?id=53219

Note that the SSLCompession configuration option was not added in response to CRIME, but was requested and implemented earlier.  Also see comment #5 that describes workaround that can be used for httpd / mod_ssl in existing Red Hat Enterprise Linux version without further changes.

Comment 18 Tomas Hoger 2012-12-11 16:58:29 UTC
Created openssl tracking bugs for this issue

Affects: fedora-all [bug 886173]

Comment 30 errata-xmlrpc 2013-03-04 21:15:46 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 6

Via RHSA-2013:0587 https://rhn.redhat.com/errata/RHSA-2013-0587.html

Comment 31 Tomas Hoger 2013-03-11 13:25:42 UTC
(In reply to comment #5)
> The openssl packages in Red Hat Enterprise Linux 5 (starting with
> RHBA-2009:0181 update released in Red Hat Enterprise Linux 5.3) and 6, and
> also in Fedora, contain a patch that makes the library check if
> OPENSSL_NO_DEFAULT_ZLIB environment variable is set (can have arbitrary
> value, even empty string) and disable the default zlib support.

Updated openssl packages from RHSA-2013:0587 (see comment 30 above) do not longer enable zlib compression support by default.  Therefore, OPENSSL_NO_DEFAULT_ZLIB environment variable is no longer checked.  Instead, they now check for the OPENSSL_DEFAULT_ZLIB environment variable, which can be used to enable zlib compression support by default.

Comment 32 Tomas Hoger 2013-03-12 22:24:17 UTC
Created mingw32-openssl tracking bugs for this issue

Affects: epel-5 [bug 920869]

Comment 33 Tomas Hoger 2013-03-12 22:24:25 UTC
Created mingw-openssl tracking bugs for this issue

Affects: fedora-all [bug 920868]

Comment 34 errata-xmlrpc 2013-03-13 14:47:29 UTC
This issue has been addressed in following products:

  RHEV-H and Agents for RHEL-6

Via RHSA-2013:0636 https://rhn.redhat.com/errata/RHSA-2013-0636.html

Comment 35 Tomas Hoger 2013-04-19 16:21:39 UTC
OpenSSL packages in Red Hat Enterprise Linux 5 and 6 were updated to no longer enable by default (comment 31).

NSS, GnuTLS, and Java/JSSE packages either do support compression, or do not enable it by default (see comments above).

OpenSSL packages included in JBoss product versions for non-RHEL platforms (Windows, Solaris) are not built with zlib support and hence were not affected by this problem.

Comment 37 errata-xmlrpc 2014-04-17 12:27:01 UTC
This issue has been addressed in following products:

  RHEV Manager version 3.3

Via RHSA-2014:0416 https://rhn.redhat.com/errata/RHSA-2014-0416.html


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