Bug 921947 (CVE-2013-2566)

Summary: CVE-2013-2566 SSL/TLS: Attack against RC4 stream cipher
Product: [Other] Security Response Reporter: Huzaifa S. Sidhpurwala <huzaifas>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: emaldona, erich, jorton, kdudka, kengert, tmraz
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: 2013-09-17 06:53:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 921950    

Description Huzaifa S. Sidhpurwala 2013-03-15 10:18:55 UTC
A new attack was discovered against TLS that allows an attacker to recover a limited amount of plaintext from a TLS connection when RC4 encryption is used. The attacks arise from statistical flaws in the keystream generated by the RC4 algorithm which become apparent in TLS ciphertexts when the same plaintext is repeatedly encrypted at a fixed location across many TLS sessions.

Reference:

http://www.isg.rhul.ac.uk/tls/
http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html

Comment 1 Tomas Hoger 2013-03-15 14:12:29 UTC
CVE-2013-2566:

The RC4 algorithm, as used in the TLS protocol and SSL protocol, has
many single-byte biases, which makes it easier for remote attackers to
conduct plaintext-recovery attacks via statistical analysis of
ciphertext in a large number of sessions that use the same plaintext.

Reference:
http://cr.yp.to/talks/2013.03.12/slides.pdf

Comment 3 Huzaifa S. Sidhpurwala 2013-06-17 06:32:27 UTC
There has been a lot of discussion about this flaw in various upstream security lists and bugzilla's for products shipped in Red Hat Enterprise Linux which support RC4. The general consensus is that, this is really a RC4 design issue and there seems to be no way to correct this flaw. 

Some workarounds to this issue were suggested like doing 1/1/1/.../n-11 record splitting at the start of the TLS connection which will burn off the first 256 predictable keystream bytes. However there are other bytes in the RC4 keystream which have biases as well, so this is only a temporary solution.

One solution is to switch over to AES-CBC mode (with fixes applied for BEAST and other related vulnerabilities) or to use TLS 1.1+ 

Note, that exploiting this flaw requires an active MITM attacker and a large number of carefully constructed requests to be sent by the client to the server, and a large number of TLS sessions. For example it was found that as much as 2^24 sessions may be needed to recover the first few bytes of plain text with "high probability".

Another possible work around would be to list RC4 below other secure cipher suites when doing TLS handshake.

Comment 4 Huzaifa S. Sidhpurwala 2013-07-09 03:00:31 UTC
More references:

Research paper: http://www.isg.rhul.ac.uk/tls/RC4biases.pdf
Vendors Patches: http://www.isg.rhul.ac.uk/tls/#Patches

Comment 5 Tomas Hoger 2013-08-01 07:51:16 UTC
Ivan Ristić's blog post which explains how Qualys SSL test currently rates RC4 compared to BEAST/CBC:
https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what

Comment 6 Huzaifa S. Sidhpurwala 2013-11-19 05:29:17 UTC
NSS lowered the priority of RC4 in cipher suite advertisement so that more secure ciphers instead of RC4 are likely to be chosen by the server.

Reference:

http://www.mozilla.org/security/announce/2013/mfsa2013-103.html
https://developer.mozilla.org/en-US/docs/NSS/NSS_3.15.3_release_notes

Comment 7 Huzaifa S. Sidhpurwala 2013-11-19 06:28:02 UTC
Also NSS patch for comment #6:
https://hg.mozilla.org/projects/nss/rev/9f313e08bd43

Comment 8 Huzaifa S. Sidhpurwala 2013-12-05 06:05:20 UTC
Further to comment #3 on this bug, this flaw exists with the inherent design of the RC4 algorithm and is therefore not specific to any implementation. Several research in cryptography has suggested making changes to RC4, but doing that would change the very algorithm used and is therefore not practical.

A work around to this issue would be to lower the priority of RC4 in cipher suite advertisement so that more secure ciphers are likely to be chosen (similar to what NSS has done, as described in comment #6 and comment #7)

Comment 9 Huzaifa S. Sidhpurwala 2013-12-05 06:07:10 UTC
Statement:

This flaw is related to the design of the RC4 protocol and not its implementation. More details and a possible work around is mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=921947#c8. Therefore there are no plans to correct this issue in Red Hat Enterprise Linux 5 and 6.