Mozilla Security Blog
Categories: Security

Attack against TLS-protected communications

Shannon Prior

6 responses

UPDATE 10.18.11: Today, Oracle is releasing a patch update to Java SE to address this vulnerability.  We recommend that users update their Java plugin to ensure that they have the latest and most secure fixes.  Windows users on auto update should start seeing the updates as early as this week.  Users can also manually download the update here: http://java.com.  Apple distributes Java updates directly for OS X.  We will not be blocking vulnerable versions of Java at this time, though we will continue to monitor for incidents of this vulnerability being exploited in the wild.

Issue

Juliano Rizzo and Thai Duong recently presented a paper detailing an information stealing attack against TLS-protected communications.  The attack is not Firefox specific, and Firefox is not vulnerable in default configurations, however some plugins may be.

Impact to users

A successful application of this man-in-the-middle attack would allow an attacker to steal information from encrypted communications. This could include cookie data, which may allow the attacker to impersonate the victim.

Status

Firefox itself is not vulnerable to this attack. While Firefox does use TLS 1.0 (the version of TLS with this weakness), the technical details of the attack require the ability to completely control the content of connections originating in the browser which Firefox does not allow.

The attackers have, however, found weaknesses in Java plugins that permit this attack. We recommend that users disable Java from the Firefox Add-ons Manager as a precaution. We are currently evaluating the feasibility of disabling Java universally in Firefox installs and will update this post if we do so.

Credit

This bug was reported by Juliano Rizzo and Thai Duong.

6 comments on “Attack against TLS-protected communications”

  1. sudjansu wrote on

    what about the javascript side channel attack? they claim it works “on all browsers”

  2. jony wrote on

    ouch http://pastie.org/2603736

  3. n wrote on

    The post is light on details, which makes me very wary. Does the attack work, for instance if the attacker can place a flash application on the website?

    Does your endorsement of security rely on the assumption that websites will only serve safe advertisements? Or that attackers cannot add code to the websites via cross-site scripting vulnerabilities?

  4. Daniel Veditz wrote on

    sudjansu:

    They haven’t shared details of the javascript side-channel attack so we can’t comment. The TLS fix we’re testing will stop any browser-based attacks if there really are any.

    jony:

    not sure what you’re saying. By itself that snippet doesn’t do much.

  5. Daniel Veditz wrote on

    n:

    We have not seen full details of the Java-based attack demoed at Ekoparty, just an earlier attack based on a version of Websockets (in the browser) that we never shipped. Our “endorsement of security”(?) is only that we don’t believe there are other avenues of attack using a browser alone. As mentioned in my previous comment we’re testing a fix to TLS 1.0 that will stop them all even if we missed any. This fix breaks communication with a small percentage of servers (current estimate roughly one in a thousand) so we’re proceeding carefully.

    Plugins are another story. From what we know of Flash we don’t think there would be a way to use it in this attack, but we’re not Flash experts. There are other plugins that have similar features that might be capable of being abused; we don’t know. We’re certainly NOT assuming sites serve only safe advertisements. But more importantly, the BEAST only works because the attacker is able to perform a Man-in-the-middle (MITM) attack on the user. It doesn’t matter HOW safe a website is, the MITM simply serves you the content they want unless the site is using TLS. If you browse to a single site that makes a single non-TLS request then the attacker can use that to launch the attack.

  6. Lake F. wrote on

    Why aren’t you advising people use noscript to block all java except from organization deployments using the java plugin? Don’t you think it would work? We would really like a way to have our organizational “enterprise” applets to be able to be deployed in firefox as we have done for years. (Note: organizations that are NOT part of IBM or Oracle or other corporate enterprise vendors run technologies from those enterprise vendors. Please try not to know the lowly customers out with the enterprise bathwater 🙂

    Related suggestion: why not have firefox have an option for people to see calls to a plugin. (and possibility to approve them or not?) In the case of java it would be very good to know how websites are calling java, especially if they are using the java webstart/jnlp approach. Java web start has major rights to mess with the client. I’d really like to know how we are being attacked, from what kind of code it is launched.