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

Status: RESOLVED INVALID

(Core :: Security, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ 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.

Comment 1

[Benjamin Smedberg]

Do you mean binary plugins? What could we possibly do about them? Or do you mean addons or something else?

Comment 2

[Daniel Veditz [:dveditz]]

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.

Comment 3

[Johnny Stenback (:jst)]

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.

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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.

Comment 6

[Ian Melven :imelven]

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.

Comment 7

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I filed bug 689661 for blocklisting the Java plugin.

Comment 8

[Josh Aas]

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.

Comment 9

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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.

Comment 10

[Ian Melven :imelven]

(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."

Comment 11

[Ian Melven :imelven]

Other possible plugins to consider : Quicktime, Windows Media Player plugin, Acrobat Reader Plugin.

Comment 12

[Ian Melven :imelven]

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.

Comment 13

[Steve Manzuik]

I will follow up with Silverlight as well and get back asap.

Comment 14

[Ian Melven :imelven]

(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)

Comment 15

[Steve Manzuik]

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)

Comment 16

[Ian Melven :imelven]

(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.

Comment 17

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(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?

Comment 18

[Steve Manzuik]

(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

Comment 19

[Al Billings [:abillings - ex-MoCo]]

No movement here in four months. What is left to be done in this bug?

Comment 20

[Ian Melven :imelven]

(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 ?

Comment 21

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 22

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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.

Comment 23

[Ian Melven :imelven]

(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.

Comment 24

[Al Billings [:abillings - ex-MoCo]]

The work is being tracked in other bugs and efforts. Marking this as "Won't Fix" per above discussion.

Comment 25

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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.