Bug 779952 - VUL-0: CVE-2012-4929: openssl: CRIME attack
VUL-0: CVE-2012-4929: openssl: CRIME attack
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
maint:released:sle11-sp1:49541 maint:...
:
Depends on:
Blocks: 793420
  Show dependency treegraph
 
Reported: 2012-09-12 11:09 UTC by Sebastian Krahmer
Modified: 2013-04-23 07:59 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Krahmer 2012-09-12 11:09:07 UTC
Seems like a new attack against SSL is upcoming, called 'CRIME'.
It claims to be able to steal session cookies from HTTPS sessions.

Check here:
http://security.blogoverflow.com/2012/09/how-can-you-protect-yourself-from-crime-beasts-successor/
Comment 1 Swamp Workflow Management 2012-09-12 22:00:19 UTC
bugbot adjusting priority
Comment 2 Guan Jun He 2012-09-13 02:47:24 UTC
So, turn off the compression --or-- add a switch(in default it's turned off).

Marcus, any idea?
Comment 3 Marcus Meissner 2012-09-13 06:35:40 UTC
We should wait for details on the actual issue, currently it is just guess work.
Comment 4 Marcus Meissner 2012-09-14 07:40:35 UTC
https://lwn.net/Articles/516038/

https://threatpost.com/en_us/blogs/crime-attack-uses-compression-ratio-tls-requests-side-channel-hijack-secure-sessions-091312

full quoting last page:
"
The new attack on TLS developed by researchers Juliano Rizzo and Thai Duong takes advantage of an information leak in the compression ratio of TLS requests as a side channel to enable them to decrypt the requests made by the client to the server. This, in turn, allows them to grab the user's login cookie and then hijack the user's session and impersonate her on high-value destinations such as banks or e-commerce sites.

The attack, known as CRIME, works on any version of TLS and the number of requests that the attacker needs to make in order to execute it is quite small, as low as six requests per cookie byte. The implications of the attack are considerable, given how widely TLS is used and the implicit trust that's the key to its utility. Rizzo and Duong's attack--their second such attack on TLS and SSL in the last two years--improves upon their previous results in that it doesn't necessarily require the use of JavaScript and it can't be defeated by changing to a different ciphersuite.

"Basically, the attacker is running script in Evil.com. He forces the browser to open requests to Bank.com by, for example, adding <img> tags with src pointing to Bank.com," Rizzo said. "Each of those requests contains data from mixed sources."
In these requests, attacker data and data produced by the browser is compressed and mixed together. Those requests can include the path, which the attacker controls, the browser's headers, which are public, and the cookie, which should be secret.

"The problem is that compression combines all those sources together," Rizzo added. "The attacker can sniff the packets and get the size of the requests that are sent. By changing the path, he could attempt to minimize the request size, i.e., when the file name matches the cookie."

Rizzo and Duong have produced a video demonstrating their CRIME attack being used against several sites, including Dropbox and Github. The pair contacted the affected sites they tested and the sites have removed compression from their servers.

Last year, Rizzo and Duong presented a similar attack called BEAST at the Ekoparty conference in Argentina. That technique enabled them to hijack SSL sessions by stealing users' secure cookies through JavaScript injection into the browser. That technique relied on a block-wise chosen-plaintext attack against the AES encryption algorithm and one defense against it was switching to RC4 encryption. That defense won't work against CRIME.

Rizzo said that browsers that implement either TLS or SPDY compression are known to be vulnerable. That includes Google Chrome and Mozilla Firefox, as well as Amazon Silk. But the attack also works against several popular Web services, such as Gmail, Twitter, Dropbox and Yahoo Mail. SPDY is an open standard developed by Google to speed up Web-page load times and often uses TLS encryption.

Google and Mozilla have developed patches to defend against the CRIME attack, Rizzo said, and the latest versions of Chrome and Firefox are protected. The researchers will present their results at Ekoparty next week. 
"
Comment 6 Sebastian Krahmer 2012-09-17 08:39:16 UTC
CVE-2012-4929
Comment 9 Marcus Meissner 2012-10-04 09:55:13 UTC
one more article:
http://bridge.grumpy-troll.org/2012/09/tls-crime-beast-and-you-programmer.html
Comment 10 Swamp Workflow Management 2012-10-04 10:08:24 UTC
The SWAMPID for this issue is 49514.
This issue was rated as moderate.
Please submit fixed packages until 2012-10-18.
When done, please reassign the bug to security-team@suse.de.
Patchinfo will be handled by security team.
Comment 11 Marcus Meissner 2012-10-04 10:10:23 UTC
ready made fix for QT4 is available, we will push updates for that.


So far I am wondering if we should always disable compression on openssl level,
or if we should leave this to the server/clients using openssl.
Comment 12 Marcus Meissner 2012-10-08 15:48:57 UTC
If services use our openssl, they can be force to disable compression already using

export OPENSSL_NO_DEFAULT_ZLIB=yes

in the service environment will disable it.
Comment 13 Guan Jun He 2012-10-26 02:42:39 UTC
So, we already have the switch, and no need more fix.
Comment 14 Swamp Workflow Management 2012-10-31 13:09:44 UTC
Update released for: libQtWebKit-devel, libQtWebKit4, libQtWebKit4-32bit, libqt4, libqt4-32bit, libqt4-debuginfo, libqt4-debugsource, libqt4-devel, libqt4-devel-doc-data, libqt4-qt3support, libqt4-qt3support-32bit, libqt4-sql, libqt4-sql-32bit, libqt4-sql-mysql, libqt4-sql-mysql-32bit, libqt4-sql-plugins, libqt4-sql-postgresql, libqt4-sql-postgresql-32bit, libqt4-sql-sqlite, libqt4-sql-sqlite-32bit, libqt4-sql-unixODBC, libqt4-sql-unixODBC-32bit, libqt4-x11, libqt4-x11-32bit
Products:
SLE-SERVER 11-SP1-TERADATA (x86_64)
Comment 15 Swamp Workflow Management 2012-10-31 15:11:48 UTC
openSUSE-SU-2012:1420-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 779952
CVE References: CVE-2012-4929
Sources used:
openSUSE 12.2 (src):    libqt4-4.8.1-2.4.1, libqt4-devel-doc-4.8.1-2.4.2, libqt4-sql-plugins-4.8.1-2.4.1
Comment 16 Swamp Workflow Management 2012-10-31 20:04:20 UTC
Update released for: libQtWebKit-devel, libQtWebKit4, libQtWebKit4-32bit, libQtWebKit4-x86, libqt4, libqt4-32bit, libqt4-debuginfo, libqt4-debuginfo-32bit, libqt4-debuginfo-64bit, libqt4-debuginfo-x86, libqt4-debugsource, libqt4-devel, libqt4-devel-doc-data, libqt4-qt3support, libqt4-qt3support-32bit, libqt4-qt3support-x86, libqt4-sql, libqt4-sql-32bit, libqt4-sql-mysql, libqt4-sql-mysql-32bit, libqt4-sql-mysql-x86, libqt4-sql-plugins, libqt4-sql-postgresql, libqt4-sql-postgresql-32bit, libqt4-sql-postgresql-x86, libqt4-sql-sqlite, libqt4-sql-sqlite-32bit, libqt4-sql-sqlite-x86, libqt4-sql-unixODBC, libqt4-sql-unixODBC-32bit, libqt4-sql-unixODBC-x86, libqt4-sql-x86, libqt4-x11, libqt4-x11-32bit, libqt4-x11-x86, libqt4-x86
Products:
SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP2 (i386, x86_64)
SLE-SDK 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP2 (i386, x86_64)
Comment 18 Marcus Meissner 2013-02-13 15:25:31 UTC
I think to cover all bases we should disable compression by default in openssl.

We discussed and reviewed this and there is likely no big impact. (Increased network traffic if that happens.)


If easily possible, we could add a new environment variable to enable it (default OFF), so specific setups could enable it if necessary.


compression_methods_switch.patch  is the one in SLE11 SP1 openssl, 
and basically change the trigger getenv() in there (and the documentation).
Comment 19 Erik Henrikson 2013-03-07 15:13:08 UTC
Is there a plan to get his defaulted to disable in the near future?  I do believe that this solution would be acceptable to us and our customers as long as changing the default back to "on" is privilidge protected.

We are mainly concerned with the Apache2 exposure - the QT we don't use/install.
Comment 20 Thomas Biege 2013-03-08 09:10:36 UTC
(In reply to comment #18)
> I think to cover all bases we should disable compression by default in openssl.
> 
> We discussed and reviewed this and there is likely no big impact. (Increased
> network traffic if that happens.)
> 
> 
> If easily possible, we could add a new environment variable to enable it
> (default OFF), so specific setups could enable it if necessary.
> 
> 
> compression_methods_switch.patch  is the one in SLE11 SP1 openssl, 
> and basically change the trigger getenv() in there (and the documentation).

Hm, we would change the default behavior then....
Comment 21 Thomas Biege 2013-03-08 09:19:52 UTC
(In reply to comment #19)
> Is there a plan to get his defaulted to disable in the near future?  I do
> believe that this solution would be acceptable to us and our customers as long
> as changing the default back to "on" is privilidge protected.

What do you mean with "privilege protected"?
Comment 22 Shawn Chang 2013-03-08 09:57:15 UTC
(In reply to comment #20)
> (In reply to comment #18)
> > I think to cover all bases we should disable compression by default in openssl.
> > 
> > We discussed and reviewed this and there is likely no big impact. (Increased
> > network traffic if that happens.)
> > 
> > 
> > If easily possible, we could add a new environment variable to enable it
> > (default OFF), so specific setups could enable it if necessary.
> > 
> > 
> > compression_methods_switch.patch  is the one in SLE11 SP1 openssl, 
> > and basically change the trigger getenv() in there (and the documentation).
> 
> Hm, we would change the default behavior then....
>
We could get the env var at first, if we got a var, then we use it, otherwise, just setting it to yes as a default. It will satisfy both turn off the zlib_comp in default and leave the choice to the users.
Comment 23 Thomas Biege 2013-03-08 10:59:51 UTC
Default behavior of OPENSSL_NO_DEFAULT_ZLIB changed, this *needs* to be in the update description.
Comment 24 Erik Henrikson 2013-03-08 14:40:08 UTC
(In reply to comment #21)
> (In reply to comment #19)
> > Is there a plan to get his defaulted to disable in the near future?  I do
> > believe that this solution would be acceptable to us and our customers as long
> > as changing the default back to "on" is privilidge protected.
> What do you mean with "privilege protected"?

Whatever file the config change is stored in just needs to be one that only root or administrative account can modify.  Probably safe to assume this would be the case so perhaps not worth mentioning.
Comment 25 Marcus Meissner 2013-03-08 15:42:10 UTC
We would basically switch the boolean value of "default XX, change by ENVVAR".

I also suggested renaming the environment vsariable to e.g. "OPENSSL_DEFAULT_ZLIB"



(we do not need to support the old OPENSSL_NO_DEFAULT_ZLIB anymore, as said ... it is a boolean state basically which is now default on.)
Comment 28 Marcus Meissner 2013-03-11 15:02:39 UTC
Changed behaviour now:


OPENSSL_NO_DEFAULT_ZLIB=no   means "YES, compress"
all other values of OPENSSL_NO_DEFAULT_ZLIB now mean "NO, do not compress"
Comment 29 Marcus Meissner 2013-03-27 09:12:49 UTC
changed the default for SLES now.


Probably need to consider this for openSUSE too.

But well, leave it there as is now perhaps upstream does something better.
Comment 30 Swamp Workflow Management 2013-03-27 10:05:13 UTC
Update released for: openssl, openssl-32bit, openssl-debuginfo, openssl-devel, openssl-devel-32bit, openssl-doc
Products:
SLE-SERVER 10-SP3-TERADATA (x86_64)
Comment 31 Swamp Workflow Management 2013-03-27 11:04:45 UTC
Update released for: openssl, openssl-devel, openssl-doc
Products:
SUSE-CORE 9-SP3-TERADATA (x86_64)
Comment 32 Swamp Workflow Management 2013-03-27 12:10:10 UTC
Update released for: openssl, openssl-32bit, openssl-64bit, openssl-debuginfo, openssl-devel, openssl-devel-32bit, openssl-devel-64bit, openssl-doc, openssl-x86
Products:
SLE-DEBUGINFO 10-SP4 (i386, ia64, ppc, s390x, x86_64)
SLE-DESKTOP 10-SP4 (i386, x86_64)
SLE-SDK 10-SP4 (i386, ia64, ppc, s390x, x86_64)
SLE-SERVER 10-SP4 (i386, ia64, ppc, s390x, x86_64)
Comment 33 Swamp Workflow Management 2013-03-27 12:28:16 UTC
Update released for: libopenssl-devel, libopenssl0_9_8, libopenssl0_9_8-32bit, libopenssl0_9_8-hmac, libopenssl0_9_8-hmac-32bit, libopenssl0_9_8-hmac-x86, libopenssl0_9_8-x86, openssl, openssl-debuginfo, openssl-debugsource, openssl-doc
Products:
SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP2 (i386, x86_64)
SLE-SDK 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP2 (i386, x86_64)
Comment 34 Swamp Workflow Management 2013-03-27 13:05:00 UTC
Update released for: libopenssl-devel, libopenssl0_9_8, libopenssl0_9_8-32bit, libopenssl0_9_8-hmac, libopenssl0_9_8-hmac-32bit, openssl, openssl-debuginfo, openssl-debugsource, openssl-doc
Products:
SLE-SERVER 11-SP1-TERADATA (x86_64)
Comment 35 Marcus Meissner 2013-04-12 14:57:42 UTC
Testcase is basically targeting s_client at an old host which supports compression:


openssl s_client -ssl3 -connect qam.suse.de:443

...
Compression: zlib compression
Expansion: zlib compression
...
Comment 36 Swamp Workflow Management 2013-04-15 15:53:50 UTC
Update released for: openssl, openssl-32bit, openssl-debuginfo, openssl-devel, openssl-devel-32bit, openssl-doc
Products:
SLE-DEBUGINFO 10-SP3 (i386, s390x, x86_64)
SLE-SERVER 10-SP3-LTSS (i386, s390x, x86_64)
Comment 37 Swamp Workflow Management 2013-04-22 15:57:08 UTC
Update released for: libopenssl-devel, libopenssl0_9_8, libopenssl0_9_8-32bit, libopenssl0_9_8-hmac, libopenssl0_9_8-hmac-32bit, openssl, openssl-debuginfo, openssl-debugsource, openssl-doc
Products:
SLE-DEBUGINFO 11-SP1 (i386, s390x, x86_64)
SLE-SERVER 11-SP1-LTSS (i386, s390x, x86_64)
SLES4VMWARE 11-SP1-LTSS (i386, x86_64)