Closed Bug 688008 Opened 13 years ago Closed 12 years ago

Some plugins are vulnerable to the Rizzo/Duong chosen plaintext attack on SSL/TLS 1.0

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
firefox6 - wontfix
firefox7 + affected

People

(Reporter: briansmith, Assigned: imelven)

References

Details

(Keywords: sec-vector, Whiteboard: [sg:high]) 

+++ This bug was initially created as a clone of Bug #665814 +++

Bug 665814 is about the vulnerability of NSS's libssl to the Rizzo/Duong chosen plaintext attack, as described in the paper attached to that bug (only). *This* but is about plugins that are vulnerable to the attach. If we want to prevent the attach even in the face of plugins, we will need to do other things in Gecko separately (and/or in addition to) from fixing bug 665814.
Do you mean binary plugins? What could we possibly do about them? Or do you mean addons or something else?
If the plugin is making its own network connections (e.g. flash and Java sockets) there really isn't anything we can do. I guess we could blocklist them, but until those plugins have a fixed version we can't really blocklist them if public influencers don't see an immanent threat (e.g. attacks seen in the wild, PoC code actually released not just demonstrated).

Look at Firesheep: it actually works, usable by anyone and their mother, all over the non-tech news (briefly), and still users of many of the affected sites remain vulnerable.
Brian, if I understand things correctly here this is something that you'll be taking care of in bug 665814. Over to you for now, but if there's something specific that needs to be done in plugin code here, say so and we'll figure out how to get that addressed.
Assignee: nobody → bsmith
This won't be solved by the fix in bug 665814. The researchers apparently demoed a way for a Java applet to violate same-origin policy to perform the attack in some way that I don't understand. AFAICT, Java uses its own TLS and HTTP implementations; they don't use ours, AFAICT.

I guess at this point, the most urgent thing would be to do something about Java specifically. Chrome has disabled Java by default. Eric Rescorla recommended disabling Java too.

I am re-assigning this to Josh since he deals with plugins and maybe he is familiar with what we've done in similar situations.
Assignee: bsmith → joshmoz
some options that the secteam has discussed previously are whitelisting plugins per domain, disabling plugins by default, and click-to-play for plugins (Flash in fennec is click to play at the moment, i believe). as Java was used in the demo and Chrome blocks it by default, i think there's a good argument for disabling Java by default, with a domain whitelist as a separate enhancement. click-to-play or some sort of doorhanger notification is another possibility, but personally i prefer disabling by default, with a per site opt in. we could pre-seed a whitelist of domains as an further enhancement but this may be controversial.
I filed bug 689661 for blocklisting the Java plugin.
Assigning this to someone on the security team. As I understand it the issue is 1) identifying vulnerable plugins and 2) blocking them. No code need to be written here so it's best assigned to the security team for decision-making.
Assignee: joshmoz → imelven
Ian, could you check whether Silverlight and other (massively popular) plugins have this issue? Also, please provide a brief summary of why Flash is less vulnerable to this issue.
(In reply to Brian Smith (:bsmith) from comment #9)
> Ian, could you check whether Silverlight and other (massively popular)
> plugins have this issue? Also, please provide a brief summary of why Flash
> is less vulnerable to this issue.

the TL;DR is that neither Silverlight or Flash Player permit even same origin socket connections without a socket policy file opting the server in to this access.
Details and citations follow : 

Flash:

from www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html#articlecontentAdobe_numberedheader_1:

"A SWF file may no longer make a socket connection to its own domain without a socket policy file. Prior to version 9,0,115,0, a SWF file was permitted to make socket connections to ports 1024 or greater in its own domain without a policy file."

Flash requires a socket policy file even for same domain socket connections as of Flash 9.0.124. No socket access is permitted by default, SSL or otherwise.

Silverlight:

from http://msdn.microsoft.com/en-us/library/cc645032%28v=vs.95%29.aspx: 

"For network connections using System.Net.Sockets, the security policy system in Silverlight affects both site-of-origin and cross-domain network access. A security policy is required for any connections using sockets, even when the connection is back to the site of origin."
Other possible plugins to consider : Quicktime, Windows Media Player plugin, Acrobat Reader Plugin.
i skimmed through the Reader API docs and i don't believe it can make arbitrary SSL requests. i reached out to a couple of people at Adobe to confirm.
I will follow up with Silverlight as well and get back asap.
(In reply to Steve Manzuik from comment #13)
> I will follow up with Silverlight as well and get back asap.

Steve, see https://bugzilla.mozilla.org/show_bug.cgi?id=688008#c10

i think requiring a policy file to make even same-origin socket connections mitigates this in Silverlight - please do check with them though, thanks ! 
(the mitigation assumes there isn't an active MITM of the policy file
load or that it takes place over HTTPS/SSL)
RE: https://bugzilla.mozilla.org/show_bug.cgi?id=688008#c10

I confirmed with the Silverlight folks that the documentation at http://msdn.microsoft.com/en-us/library/cc645032%28v=vs.95%29.aspx

is correct a policy file must be present at the target IP before the SL runtime will allow an app to open a socket.

Let me know if there are any other questions on any Microsoft plugins and I can chase down the answers.

Thanks

Steve Manzuik
Microsoft Vulnerability Research (MSVR)
(In reply to Ian Melven :imelven from comment #12)
> i skimmed through the Reader API docs and i don't believe it can make
> arbitrary SSL requests. i reached out to a couple of people at Adobe to
> confirm.

Confirmed with Adobe product security that Reader cannot make arbitrary SSL requests, you can embed Flash in a PDF that can, but it's subject to the same socket policy check.
(In reply to Steve Manzuik from comment #15)
> RE: https://bugzilla.mozilla.org/show_bug.cgi?id=688008#c10
> 
> I confirmed with the Silverlight folks that the documentation at
> http://msdn.microsoft.com/en-us/library/cc645032%28v=vs.95%29.aspx
> 
> is correct a policy file must be present at the target IP before the SL
> runtime will allow an app to open a socket.

Steve, could you clarify this comment? Is it same-IP address or same-origin (i.e. same protocol, hostname, and port), or something else?

In particular, could a policy file served over HTTP be used for an HTTPS connection?
(In reply to Brian Smith (:bsmith) from comment #17)


I ran this past the Silverlight folks.

-----

>Is it same-IP address or same-origin (i.e. same protocol, hostname, and port), or something else?

For sockets, the SL runtime resolves the hostname to an IP address and gets the policy file from that IP address before it allows a socket connection.  For HTTP requests, it's just same-origin (protocol+hostname+port).

>In particular, could a policy file served over HTTP be used for an HTTPS connection?

No, http://foo.com can't speak for https://foo.com, they're treated as distinct endpoints.

This page might be helpful: http://msdn.microsoft.com/en-us/library/cc645032(v=vs.95).aspx
No movement here in four months. What is left to be done in this bug?
(In reply to Al Billings [:abillings] from comment #19)
> No movement here in four months. What is left to be done in this bug?

good question. This bug describes a valid issue, there are many old versions of plugins vulnerable to the BEAST attack, so INVALID seems wrong. WONTFIX doesn't seem appropriate, because we do want to (and are doing) something to help address the issues around plugins - see https://wiki.mozilla.org/Opt-in_activation_for_plugins. WORKSFORME seems wrong for similar reasons. 

we could unhide it and set it to depend on the click to play bug ? or one of the bugs around improving the plugin blocklisting UI/experience ?
If we know of specific problems, I'd like them to get their own bugs opened on their issue. These "meta" type bugs wind up often unactionable.
I think the "fix" is to stop to plugins that are (and/or might be) vulnerable to the BEAST from working. I think we're not going to do that--in fact, I don't think we're planning to do anything special based on whether we think there's any particular vulnerability in any plugin. So, I think WONTFIX is correct.
(In reply to Brian Smith (:bsmith) from comment #22)
> I think the "fix" is to stop to plugins that are (and/or might be)
> vulnerable to the BEAST from working. I think we're not going to do that--in
> fact, I don't think we're planning to do anything special based on whether
> we think there's any particular vulnerability in any plugin. So, I think
> WONTFIX is correct.

There's discussion about using click to play to block old/vulnerable versions of plugins and driving the click to play experience for plugins via the blocklist. That would at least stop those plugins loading and executing content without, for example, a user clicking through a scary warning that says the plugin they're about to let execute has a known vulnerability.
The work is being tracked in other bugs and efforts. Marking this as "Won't Fix" per above discussion.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Keywords: sec-vector
Changing resolution to INVALID since this isn't considered a bug in Gecko or Firefox (it's a bug in third-party software). And, opening bug as there's nothing security-sensitive or confidential here.
Group: core-security
Resolution: WONTFIX → INVALID
You need to log in before you can comment on or make changes to this bug.