This is a security assessment of the BEAST SSL security vulnerability announced at the Ekoparty conference. Voir aussi 94262.

Contents

  1. Background
  2. Vulnerable software
  3. Not vulnerable
  4. Workarounds
  5. Fixes
  6. Recommendation
    1. New recommendation, server side
  7. Rejected recommendations
  8. References

Background

The Tor project has a good technical writeup of the issue. The attack demonstrated that it was possible for a malicious site evil.com to fetch the cookies from (say) https://gmail.com/ if the user visited the two sites within some time frame (~10 minutes), through the use of web sockets (javascript, java or flash, for example).

The attack works by exploiting a weakness in the TLS 1.0 protocol (or SSL 3.1 and earlier) where the IV (Initialisation Vector) for the CBC (Chain Block Cipher, e.g. AES) is based on the previous message instead of being random. In short, by injecting known traffic in the encrypted stream in a pre-determined location, it is able to basically hijack the initialization vector of specific parts of the traffic, and therefore decrypt the traffic following it.

BEAST stands for "Browser Exploit Against SSL/TLS".

Vulnerable software

Not vulnerable

Workarounds

Tor starts new SSL messages with an empty message, which mitigates the attack. There is a compile flag in OpenSSL (SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS set to _dis_abled) that would reproduce this behavior and mitigate the attack but may cause compatibility issues.

Another workaround is to prioritize the RC4 cipher over the others (source), but that old cipher has a lot of well-known security issues.

Turning off Java and maybe even Javascript and Flash in your web browser would also make the unworkable.

Fixes

TLS 1.1 and 1.2 fix the issues, but are not supported in OpenSSL (or rather OpenSSL started supporting 1.1 only recently). Even worse, as mentionned by the ISC, only Opera and certain versions of Internet explorer support TLS 1.1 and above. There is a way to run TLS 1.2 enable TLS 1.2 in apache using GnuTLS, however.

Chromium a seem to have worked around the issue, by adding some random data in the IV to throw the attackers off-track (see this patch) although it wasn't announced on the Mozilla security advisory page. The Mozilla blog seems to assert that Firefox is not vulnerable out of the box, without giving extra details, and even though they did implement a fix similar to Chrome's.

Recommendation

For users

disable java, and if possible javascript and flash, and enable only on a site-by-site basis, using NoScript and Flashblock in Firefox, or by turning off plugins, java and javascript in Chromium (a little button will appear to re-enable them as needed)

For administrator

Start adopting GnuTLS instead of OpenSSL as a cryptographic framework, lobby for implementation of proper standards (NSS (Chrome and Firefox),

New recommendation, server side

Apparently, we could work around the issue by changing the ciphers, even if we're not using RC4. to be studied further. See 94262. -- TheAnarcat 2013-01-15 13:41:46

Rejected recommendations

  1. use RC4 over the other ciphers: 
    • SSLHonorCipherOrder on
SSLCipherSuite RC4-SHA:RC4-MD5:!ADH:HIGH:MEDIUM

      • (!) an even more restrictive list (RC4-SHA:!MD5:!ADH:!3DES:!DES:HIGH:MEDIUM) is in testing on https://shell.koumbit.net, feedback welcome:

        • Chromium 13 (./)

        • Iceweasel 7 (./)

        • IE8 (./)

<!> This was rejected because numerous vulnerabilities in RC4 are known and could probably be exploited without any third party malicious software, see Wikpedia:RC4. -- TheAnarcat 2011-10-07 14:07:06

References

CatégorieSecurité

BeastSecurityAssessment (last edited 2013-01-15 13:41:46 by TheAnarcat)