Support option to disable TLS compression to protect against CRIME attack

Bug #1068854 reported by Reed Loden
288
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Apache2 Web Server
Fix Released
Wishlist
apache2 (Debian)
Fix Released
Unknown
apache2 (Fedora)
Fix Released
Medium
apache2 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Upstream Apache recently committed a change to be in Apache 2.2.24 (not yet released) that would allow for disabling TLS compression to protect against the CRIME attack. As it's probably going to be a way before 2.2.24 is released, it would be great to backport this patch as a one-off SRU to at least precise (LTS) and quantal until the new release. There's also been some mention that supporting TLS compression is possibly causing some people's PCI compliance tests to fail, so having this option would be extremely useful to help pass their compliance tests (plus just protecting against CRIME and CRIME-like attacks).

More info:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53219
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674142
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689936
https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls
http://isecpartners.com/blog/2012/9/14/details-on-the-crime-attack.html

CVE References

Revision history for this message
In , Björn Jacke (bjoern-j3e) wrote :

downloading large ammount of data via ssl this is not too cpu consuming on recent CPUs but with browsers that support ssl compression you can see very CPU intensive apache processes due to ssl compression being done. instread of 2% cpu time (encryption only) 50% cpu time (compression+encrytion) will be taken by one apache process in a test.

There is no way to disable ssl compression in mod_ssl even though openssl has "SSL_OP_NO_COMPRESSION" which can be enabled via SSL_CTX_set_options since 1.0.0. For scalability reasons it would be required that ssl compression can be turned off in mod_ssl. I would even suggest to turn it off by default because mod_deflate is doing a much better job and can be better tuned by file types etc.

Revision history for this message
In , Björn Jacke (bjoern-j3e) wrote :

Created attachment 28782
patch to add SSLCompession On/Off parameter

I've created a patch which adds the parameter SSLCompession which can be set to On or Off. By default it uses the default of the SSL library. This patch is against 2.2 but it also applies to 2.4 with some offsets.

Revision history for this message
In , Björn Jacke (bjoern-j3e) wrote :

Created attachment 28804
patch to disable ssl compression

this version of the patch now works with openssl 0.9.8 and newer

Revision history for this message
In , Stefan Fritsch (sf-sfritsch) wrote :

Committed to trunk as r1345319 with some tweak to abort with an error when trying to configure compression in virtual-host scope with openssl 0.9.8 (which can only enable/disable compression globally).

Revision history for this message
In , Rainer Jung (rainer-jung-kippdata) wrote :

Backported to 2.4.x in r1369585.
Will be part of 2.4.3.

Revision history for this message
In , Rainer Jung (rainer-jung-kippdata) wrote :

Released with 2.4.3.
Leaving open for possible back port to 2.2.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

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

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

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

Revision history for this message
In , Vincent (vincent-redhat-bugs) wrote :

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.

Revision history for this message
In , Reed Loden (reed) wrote :

(In reply to comment #5)
> Leaving open for possible back port to 2.2.

Considering the potential of abuse of SSL/TLS compression by the new CRIME attack (https://threatpost.com/en_us/blogs/crime-attack-uses-compression-ratio-tls-requests-side-channel-hijack-secure-sessions-091312), can this back port request be prioritized and completed so folks can easily disable SSL/TLS compression if needed? Thanks!

Revision history for this message
In , Covener-0 (covener-0) wrote :

proposed for 2.2.x

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :
Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

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/

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

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.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

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.

Revision history for this message
In , Vincent (vincent-redhat-bugs) wrote :
Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

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

Revision history for this message
In , Huzaifa (huzaifa-redhat-bugs) wrote :

Mozilla assigned CVE-2012-3977 to the SPDY flaw in Firefox and Seamonkey. The CVE is being tracked via the bug #859827.

Revision history for this message
In , Markus (markus-redhat-bugs) wrote :

(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?

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

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.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :
Revision history for this message
In , Chris-christopherschultz (chris-christopherschultz) wrote :

I'd love to see this in 2.2.x as well, since many Linux distros still aren't supporting 2.4.x, and protection against CRIME is certainly a nice thing to have.

Revision history for this message
In , Bzasf (bzasf) wrote :

Backported to 2.2.x in r1395231. To appear in 2.2.24.

Revision history for this message
In , Christoph Anton Mitterer (calestyo) wrote :

Hi.

It's good to see this backported...

However,... I'm a bit concerned...

As far as I understood,... _ALL_ versions of SSL/TLS are vulnerable to the CRIME attack, right?

So why is compression not forcefully disabled? Not with respect to speed (as originally intended by Björn) but to security.

If newer versions of TLS should fix the attack.... one could allow them to select whether compression should be used or not.

Ideas?

Revision history for this message
In , Chris-christopherschultz (chris-christopherschultz) wrote :

(In reply to comment #9)
> Backported to 2.2.x in r1395231. To appear in 2.2.24.

Great! Now, to get Debian to actually put this patch into a release channel...

Revision history for this message
In , Christoph Anton Mitterer (calestyo) wrote :

I've already opened http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689936 .

Nevertheless, as I've mentioned in comment 10, Apache should handle this more by itself.

Revision history for this message
In , Björn Jacke (bjoern-j3e) wrote :
Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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)

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

(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.

Revision history for this message
Reed Loden (reed) wrote :

Note that Red Hat already supports a workaround [0] that allows for disabling zlib at the OpenSSL layer, which prevents TLS compression working in Apache. As far as I am aware, no such option exists for Ubuntu, leaving users vulnerable until a new package is available.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=857051#c5

Revision history for this message
In , Stefan Fritsch (sf-sfritsch) wrote :

The default has been changed to "off" in r1400700

Robie Basak (racb)
information type: Public → Public Security
Revision history for this message
In , Reed Loden (reed) wrote :

(In reply to comment #14)
> The default has been changed to "off" in r1400700

That's only on trunk, right? What about the default for 2.2.x and 2.4.x?

Changed in apache2 (Debian):
status: Unknown → Confirmed
Revision history for this message
In , Christoph Anton Mitterer (calestyo) wrote :

Hi Stefan.

1) Are you going to backport this into the Debian versions?

2) As long as there is no protocol level fix (or something like this), wouldn't it be better to generally and forcibly switch that off in the affected versions?
I mean if someone would really want it in spite of the attack,... he should probably be able to patch the code accordingly.
Otherwise people may just think that compression sounds like a good thing and "accidentally" enable it (which leads me to: (3)).

3) As far as I can see, the documentation of this directive does not refer to the CRIME attack.
Unless (2) was done (and thus people can't accidentally enable it) I'd strongly recommend adding information that switching compression on allows the CRIME attack and which versions of SSL/TLS/etc. are affected (unless all are).

Cheers,
Chris.

Revision history for this message
In , Stefan Fritsch (sf-sfritsch) wrote :

(In reply to comment #15)
> (In reply to comment #14)
> > The default has been changed to "off" in r1400700
>
> That's only on trunk, right? What about the default for 2.2.x and 2.4.x?

They will be changed, too. But due to the voting on backports, it will take a bit. For 2.4.x, the change has been committed as r1400962 and will be in 2.4.4.

(In reply to comment #16)
> 1) Are you going to backport this into the Debian versions?

Yes.

> 2) As long as there is no protocol level fix (or something like this),
> wouldn't it be better to generally and forcibly switch that off in the
> affected versions?
> I mean if someone would really want it in spite of the attack,... he should
> probably be able to patch the code accordingly.
> Otherwise people may just think that compression sounds like a good thing
> and "accidentally" enable it (which leads me to: (3)).
>
> 3) As far as I can see, the documentation of this directive does not refer
> to the CRIME attack.
> Unless (2) was done (and thus people can't accidentally enable it) I'd
> strongly recommend adding information that switching compression on allows
> the CRIME attack and which versions of SSL/TLS/etc. are affected (unless all
> are).

The documentation now states "Enabling compression causes security issues in most setups (the so called CRIME attack)." I think that is sufficient.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apache2 (Ubuntu):
status: New → Confirmed
Changed in apache2 (Debian):
status: Confirmed → Fix Released
Revision history for this message
Reed Loden (reed) wrote :

Debian just released apache2 v2.2.22-12 to address this issue.

Revision history for this message
In , Christoph Anton Mitterer (calestyo) wrote :

Thanks.

btw: Does anyone know whether SSL/TLS is going to be fixed? I mean in a way that CRIME is not working while still being able to use TLS compression?

Changed in apache2 (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Reed Loden (reed) wrote :

Virendra, as far as I know, this isn't in any released Apache version.

Changed in apache2 (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apache2 - 2.2.8-1ubuntu0.24

---------------
apache2 (2.2.8-1ubuntu0.24) hardy-security; urgency=low

  * SECURITY UPDATE: XSS vulnerability in mod_negotiation
    - debian/patches/224_CVE-2012-2687.dpatch: escape filenames in
      modules/mappers/mod_negotiation.c.
    - CVE-2012-2687
  * SECURITY UPDATE: CRIME attack ssl attack (LP: #1068854)
    - debian/patches/225_CVE-2012-4929.dpatch: backport SSLCompression
      on|off directive. Defaults to off as enabling compression enables the
      CRIME attack.
    - CVE-2012-4929
 -- Marc Deslauriers <email address hidden> Tue, 06 Nov 2012 15:01:07 -0500

Changed in apache2 (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

Created openssl tracking bugs for this issue

Affects: fedora-all [bug 886173]

Revision history for this message
In , Wrowe (wrowe) wrote :

Stephan, I didn't catch the r1400962 backport in STATUS, and it didn't appear
to be committed yet to 2.2. Could you add to 2.2 STATUS so we can +1 the
change before a 2.2.24?

Revision history for this message
In , Stefan Fritsch (sf-sfritsch) wrote :

fixed in 2.4.4 and 2.2.24

Revision history for this message
In , errata-xmlrpc (errata-xmlrpc-redhat-bugs) wrote :

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

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

(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.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

Created mingw32-openssl tracking bugs for this issue

Affects: epel-5 [bug 920869]

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

Created mingw-openssl tracking bugs for this issue

Affects: fedora-all [bug 920868]

Revision history for this message
In , errata-xmlrpc (errata-xmlrpc-redhat-bugs) wrote :

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

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

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.

Revision history for this message
In , errata-xmlrpc (errata-xmlrpc-redhat-bugs) wrote :

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

Revision history for this message
In , Muthamilan (muthamilan) wrote :

Hello All,

I'm using httpd-2.2.22-win32-x86-openssl-0.9.8t. I want to disable the Compression algorithms to resolve the SSL/TLS Compression Algorithm Information Leakage Vulnerability.

Please guide me.

Thanks
Muthu
<email address hidden><email address hidden>

Revision history for this message
In , Ylavic-dev (ylavic-dev) wrote :

You can't reopen a fixed report because it does not fit your version.
This is implemented in 2.2.24, just use that version or better, the latest 2.2 (currently 2.2.29).

Revision history for this message
In , Muthamilan (muthamilan) wrote :

Hello Yann,

I'm new to this fourm.

Sorry I wrongly changed the status.

As per your update, I have to upgrade my Apache version to disable SSL compression.

please guide me

Thanks,
Muthu

Revision history for this message
In , Ylavic-dev (ylavic-dev) wrote :

Bugzilla is for reporting bugs, not for support.
Please use the users mailing-list (<email address hidden>) and/or read http://httpd.apache.org/docs/2.2/install.html.

Changed in apache2 (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Released
Revision history for this message
In , Kmidatarecovery (kmidatarecovery) wrote :

(In reply to Christoph Anton Mitterer from comment #18)
> Thanks.
>
> btw: Does anyone know whether SSL/TLS is going to be fixed? I mean in a way
> that CRIME is not working while still being able to use TLS compression?

Hi,

I'm using ddlutils 1.0 and tomcat jdbc pool 1.0.7.1 and I getting an error
due to a connection is closed and the pool is not aware of that.
Basically the issue is that ddlutils has a resultset iterator and when it
finishes it closes the connection by getting it from the *
resultSet.preparedStatement.connection* and the connection returned is not
the proxy that the pool has created.

So the issue happens when another client retrieves a connection from the
pool because the pool returns a connection that was actually closed.
Why tomcat jdbc pool is not creating proxies for preparedStatements and
resultSets like commons-dbcp?

Is there any other way to address this issue?

Thanks

Antonio - https://kmidata.es/

Revision history for this message
In , Covener-0 (covener-0) wrote :

>
> I'm using ddlutils 1.0 and tomcat jdbc pool 1.0.7.1 and I getting an error
> due to a connection is closed and the pool is not aware of that.

off-topic for this closed httpd bug.

Changed in apache2:
importance: Unknown → Wishlist
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.