Closed Bug 689661 Opened 13 years ago Closed 13 years ago

Block Java Plugin due to security vulnerabilities (BEAST TLS and bug in same-origin-policy)

Categories

(Toolkit :: Blocklist Policy Requests, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox6 - affected
firefox7 + affected
firefox8 + wontfix

People

(Reporter: briansmith, Assigned: fligtar)

References

Details

(Whiteboard: [sg:vector-high])

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

I recommend that we blocklist all versions of the Java Plugin.

As far as I understand the situation, If all of these apply:

(1) The attacker can control the user's network connection, and
(2) The attacker can perform DNS rebinding or similar
(3) The user loads any non-HTTPS page, or the user loads an HTTPS page controlled by the attacker
(4) The Java plugin is enabled

then, the attacker will be able to steal the user's *existing* session cookies for any website, including any *HTTPS* website that the user visits, even when the cookies are marked Secure and HttpOnly. So, for example, the attacker would be able to steal the uesr's Google mail cookie, Paypal cookie, bugzilla.mozilla.org cookie, mail.mozilla.com cookie, etc., allowing the attacker to log in as the user.

My understanding is that Oracle may or may not be aware of the details of the same-origin exploit. As of now, we have no ETA for a fix for the Java plugin.
Doorhanger-style click-to-play won't work so well for non-HTTPS pages, because the attack requires a MITM. Since the attacker is MITMing the user, he can inject his applet into every non-HTTPS page in an undetectable (to the user) way. That means, whenever the user clicks to play, they are at risk of running attackers' applets.
To clarify, as far as I know, the attack requires the SOP exploit AND the MitM attack with BEAST.
(In reply to Brian Smith (:bsmith) from comment #0)
> +++ This bug was initially created as a clone of Bug #688008 +++
> +++ This bug was initially created as a clone of Bug #665814 +++
> 
> I recommend that we blocklist all versions of the Java Plugin.
> 
> As far as I understand the situation, If all of these apply:
> 
> (1) The attacker can control the user's network connection, and
> (2) The attacker can perform DNS rebinding or similar
> (3) The user loads any non-HTTPS page, or the user loads an HTTPS page
> controlled by the attacker
> (4) The Java plugin is enabled

(5) The victim Web site also prefers AES or 3DES to RC4 when offered the
choice.
Eric has notified Oracle about some SOP bypass bug he himself discovered. Thanks Eric! It may or may not be the same SOP bypass that Rizzo & Duong used in their demo. (And thanks, Eric, for correcting my omission above.)

Juliano Rizzo seems to think it is likely that the BEAST attack can be made to work without the SOP bypass. That would be a good operating assumption to make, unless/until we become determined otherwise.
I want to be careful not to overclaim credit here. I started looking at the behavior of URLConnection after seeing the Rizzo/Duong talk and reading the relevant stuff in the browser security handbook and some of those behaviors seem problematic. It's entirely possible that either (a) I'm crazy or (b) I'm just confirming behaviors that people already know, though perhaps they didn't think they were as problematic....
Assignee: nobody → joshmoz
In the interest of keeping this bug updated with the latest status, this morning I asked Johnath for some help in understanding the balance between the horrible user experience this would cause and the severity/prevalence of the security issue and am waiting to hear back.

We also discussed this in the Products team meeting today and definitely need better understanding of that before putting the block in place.
Are any members of the Enterprise Working Group cced on this bug? If this block were to occur, we would need to be very clear in our informing our large deployments of this change (many large organizations have Java applet internal tools).
Putting this URL here for future reference:

https://wiki.mozilla.org/Extension_Blocklisting:Code_Design
See Also: → 549697
(In reply to Brian Smith (:bsmith) from comment #1)
> Doorhanger-style click-to-play won't work so well for non-HTTPS pages,
> because the attack requires a MITM. Since the attacker is MITMing the user,
> he can inject his applet into every non-HTTPS page in an undetectable (to
> the user) way. That means, whenever the user clicks to play, they are at
> risk of running attackers' applets.

if this bug is specifically about BEAST, why are non-HTTPS pages an issue ?
(In reply to Ian Melven :imelven from comment #9)
> (In reply to Brian Smith (:bsmith) from comment #1)
> > Doorhanger-style click-to-play won't work so well for non-HTTPS pages,
> > because the attack requires a MITM. Since the attacker is MITMing the user,
> > he can inject his applet into every non-HTTPS page in an undetectable (to
> > the user) way. That means, whenever the user clicks to play, they are at
> > risk of running attackers' applets.
> 
> if this bug is specifically about BEAST, why are non-HTTPS pages an issue ?

specifically i am concerned that the usability concerns around blocking Java will be too difficult to overcome if we don't have a domain based whitelist or click to play. i added the click to play bug #549697 as a 'see also'.
The file names for the Java plugins are:

Mac OS X: JavaPlugin2_NPAPI.plugin
Windows: npjp2.dll
Linux: libjavaplugin.so, libnpjp2.so, IcedTeaPlugin.so

Note that I included the Iced Tea plugin in the Linux list. Not sure if we've determined that it has a problem or not.

If we choose to go ahead with this block we probably want to apply it to all versions for all users.
Assignee: joshmoz → nobody
(In reply to Ian Melven :imelven from comment #9)
> (In reply to Brian Smith (:bsmith) from comment #1)
> > Doorhanger-style click-to-play won't work so well for non-HTTPS pages,
> > because the attack requires a MITM. Since the attacker is MITMing the user,
> > he can inject his applet into every non-HTTPS page in an undetectable (to
> > the user) way. That means, whenever the user clicks to play, they are at
> > risk of running attackers' applets.
> 
> if this bug is specifically about BEAST, why are non-HTTPS pages an issue ?

The applet doesn't have to be loaded over HTTPS to be useful. In fact, it pretty much can't be. In the demo [1], they are using an applet from a non-HTTPS page on an unrelated domain name to attack PayPal.com.

[1] http://www.youtube.com/watch?v=BTqAIDVUvrU
(In reply to Brian Smith (:bsmith) from comment #12)
>
> The applet doesn't have to be loaded over HTTPS to be useful. In fact, it
> pretty much can't be. In the demo [1], they are using an applet from a
> non-HTTPS page on an unrelated domain name to attack PayPal.com.
> 
> [1] http://www.youtube.com/watch?v=BTqAIDVUvrU

oh right, hence the need (at least as far as we know currently) for a SOP bypass. thanks for clarifying. so click to play is less useful, since an applet can be injected into any page as you pointed out earlier, and the attacker just needs a 'click to play' on any non-HTTPS page. 

i need to look more into user options for opting back in for a disabled plugin and how (if it is) this is possible on a global or per domain basis.
additionally a blog post or some other communication about how to disable Java via a user controlled mechanism (pref if this is possible) probably wouldn't go amiss.
actually, a domain based whitelist isn't viable here, due to the same injection issue, an attacker could just inject the hostile applet into a non-HTTPS page on a whitelisted domain. whitelist + click to play offers some protection but is still vulnerable to the problems bsmith outlined above.
(In reply to Ian Melven :imelven from comment #14)
> additionally a blog post or some other communication about how to disable
> Java via a user controlled mechanism (pref if this is possible) probably
> wouldn't go amiss.

this has already been done, see http://blog.mozilla.com/security/2011/09/27/attack-against-tls-protected-communications/
(In reply to Justin Scott [:fligtar] from comment #6)
> In the interest of keeping this bug updated with the latest status, this
> morning I asked Johnath for some help in understanding the balance between
> the horrible user experience this would cause and the severity/prevalence of
> the security issue and am waiting to hear back.

The attack will work when the conditions mentioned in comment 3 hold. For most users, we can assume that conditions (3), (4), and (5) are met for almost every HTTPS website they visit. Conditions (1) and (2) basically boil down to "Do you trust your network connection so much that you don't need SSL anyway?" (This is oversimplified, but only a little). Most of our users would have to answer "no" to that question. 

(Nit: I mentioned Google mail in my initial comment. But, I believe that Google mail is not vulnerable to this bug in our default configuration because it prefers RC4 over other ciphers. But generally, servers are vulnerable.)
(In reply to Justin Scott [:fligtar] from comment #6)
> In the interest of keeping this bug updated with the latest status, this
> morning I asked Johnath for some help in understanding the balance between
> the horrible user experience this would cause and the severity/prevalence of
> the security issue and am waiting to hear back.
> 
> We also discussed this in the Products team meeting today and definitely
> need better understanding of that before putting the block in place.

Yeah - this is a hard call. Killing Java means disabling user functionality like facebook video chat, as well as various java-based corporate apps (I feel like Citrix uses Java, for instance?)

We do have soft-blocking now, which disables but prompts with the option to re-enable, and also allows users to re-enable from the addons manager, but it still means it's dead for most people. Click to play or domain-specific whitelisting will provide some measure of benefit, but I suspect that enough users will whitelist, e.g., facebook that even with those mechanisms (which don't currently exist!) in place, we'd have a lot of users potentially exposed to java weaknesses.

Whatever decision we make here, I really hope Oracle gets an update of their own out - it's the only way to keep their users affirmatively safe.
Isn't it the browser responsibility to provide the cookies to the plugin? The browser could just be modified to not give any cookies to the plugin, this is a much nicer solution instead of blocking the whole plugin.

Also it seems Chrome/Chromium now protects against BEAST without any needed changes to the Java Plugin.
(In reply to kappa from comment #19)
> Isn't it the browser responsibility to provide the cookies to the plugin?
> The browser could just be modified to not give any cookies to the plugin,
> this is a much nicer solution instead of blocking the whole plugin.

I second this approach but we first have to investigate if it's technically possible (other plugins also use the cookies and I don't know if we can determine what the plugin type of the requesting plugin instance is). I think Brian is working on this.

> Also it seems Chrome/Chromium now protects against BEAST without any needed
> changes to the Java Plugin.

As far as I know, Chrome has Java disabled by default, that's why they don't have to worry about it so much.
(In reply to Christian Holler (:decoder) from comment #20)
> (In reply to kappa from comment #19)
> > Isn't it the browser responsibility to provide the cookies to the plugin?
> > The browser could just be modified to not give any cookies to the plugin,
> > this is a much nicer solution instead of blocking the whole plugin.
> 
> I second this approach but we first have to investigate if it's technically
> possible (other plugins also use the cookies and I don't know if we can
> determine what the plugin type of the requesting plugin instance is). I
> think Brian is working on this.
> 
> > Also it seems Chrome/Chromium now protects against BEAST without any needed
> > changes to the Java Plugin.
> 
> As far as I know, Chrome has Java disabled by default, that's why they don't
> have to worry about it so much.

no, after reading about your discussion here earlier today on misc websites I decided to disable Java manually on my browsers (FF, Chrome, IE). It was "on" in Chrome.
... adding that I never activated it manually before that.
(In reply to logos from comment #21)
> no, after reading about your discussion here earlier today on misc websites
> I decided to disable Java manually on my browsers (FF, Chrome, IE). It was
> "on" in Chrome.

It should be "click to play" by default, which means you have to click on the applet for it to be activated and loaded. "Disabled" might have been the wrong term here, but until you click the applet, nothing can happen.
..Okay I forgot, even when Java is activated in Chrome, you always get a prompt to allow it to run if required by a site. That's by default, even with the "always run automatically" setting, you still get a prompt, you can then make an exception for a site (allow one time vs always). Same for quicktime.
(In reply to Christian Holler (:decoder) from comment #23)
> (In reply to logos from comment #21)
> > no, after reading about your discussion here earlier today on misc websites
> > I decided to disable Java manually on my browsers (FF, Chrome, IE). It was
> > "on" in Chrome.
> 
> It should be "click to play" by default, which means you have to click on
> the applet for it to be activated and loaded. "Disabled" might have been the
> wrong term here, but until you click the applet, nothing can happen.

you're right, I corrected while you were posting.
... but anyway, how will a user be able to know whether allowing a Java applet on a specific site is secure or not...
  Chrome uses a different approach it seems:
http://www.theregister.co.uk/2011/09/21/google_chrome_patch_for_beast/
(In reply to logos from comment #26)
> ... but anyway, how will a user be able to know whether allowing a Java
> applet on a specific site is secure or not...

Correct. That is exactly the reason why click to play might not be sufficient to mitigate this threat and why this bug for blocking it entirely actually exists :)

>   Chrome uses a different approach it seems:
> http://www.theregister.co.uk/2011/09/21/google_chrome_patch_for_beast/

The fix you are referring to patches NSS, the TLS library of Firefox and Chrome. This fix is unrelated to the issue discussed here, because Java does not use the NSS TLS stack.

I'd suggest that we move this to IRC (find me at irc.mozilla.org in #security) for further discussion and leave this bug alone for the people to work on this issue :)
El reg has sent their readers here ( http://www.theregister.co.uk/2011/09/29/firefox_killing_java/ ).

Hi readers! We build Firefox in the open, which means you can watch this bug and even participate, but please respect the fact that this is an active piece of work on an important topic, and avoid adding noise. The best way to help is to let the engineers and associated participants do their job here.

Engineers and associated participants: the Eye of Sauron is now upon this bug. That shouldn't stop us from doing our job, but it does mean that a certain attention should be paid to the tenor of the discourse. I'd encourage, for instance, avoiding sarcastic hyperbole (kittens are dying while we discuss this!), or rhetorical sidebars (let's just kill all plugins!) that might be taken out of context and seed confusion or concern.
(In reply to Potch [:potch] from comment #7)
> Are any members of the Enterprise Working Group cced on this bug? If this
> block were to occur, we would need to be very clear in our informing our
> large deployments of this change (many large organizations have Java applet
> internal tools).

I've put a link in the EWG mailing list so they are aware of and can review the status of this bug.
(In reply to Josh Aas (Mozilla Corporation) from comment #11)
> The file names for the Java plugins are:
> 
> Mac OS X: JavaPlugin2_NPAPI.plugin
> Windows: npjp2.dll
> Linux: libjavaplugin.so, libnpjp2.so, IcedTeaPlugin.so
> 
> Note that I included the Iced Tea plugin in the Linux list. Not sure if
> we've determined that it has a problem or not.
> 
> If we choose to go ahead with this block we probably want to apply it to all
> versions for all users.
(In reply to Josh Aas (Mozilla Corporation) from comment #11)
> The file names for the Java plugins are:
> 
> Mac OS X: JavaPlugin2_NPAPI.plugin
> Windows: npjp2.dll
> Linux: libjavaplugin.so, libnpjp2.so, IcedTeaPlugin.so
> 
> Note that I included the Iced Tea plugin in the Linux list. Not sure if
> we've determined that it has a problem or not.

I do not know what level of support we should provide for the Iced Tea plugin. I think if/when Oracle has a fix for their product, it might not immediately affect Iced Tea. And, also, we haven't verified that the Iced Tea plugin has the same security properties as the Oracle Java plugin. 

> If we choose to go ahead with this block we probably want to apply it to all
> versions for all users.

I agree.
I can't imagine IcedTea has a non-vulnerable TLS stack, but they may or may not have the SOP bug that facilitated the exploit. Depends on if it's really a "bug" or the natural outgrowth of a feature IcedTea copied. Rizzo/Duong claim they didn't need a SOP bug it just facilitated development, but it also appears they claimed to have a working exploit when proposing their talk and then came up with the actual exploit after so who knows...
Comment 30 is private: false
Hi

I contacted Oracle France today, I haven't had yet any reply. I hope that any possible vulnerabilities of the Java plugin will be fixed as soon as possible and I think that's the only viable solution on the long term.

In my humble opinion, Google Chrome is not an example and I don't expect the Mozilla Corporation to behave like a listed private corporation but rather like a non-profit organization defending open standards.

I assume that you try to protect the final users but it goes too far. Blocking Java plugin due to security vulnerabilities is almost like putting in jail everybody because we could commit crimes. This is not an open web and some other technologies have security flaws. If you decide to block Java for this reason, you will have to do the same for Javascript (including WebGL, websockets, etc...), Flash and Silverlight otherwise you will be accused of favouring some technologies over some others. You already blocked the OJI-based Java plugin 1, enough is enough. Maybe you could add a very scary warning until Oracle fixes the bugs found by some researchers, it would be more constructive than completely blocking the whole plugin. I hope Java Web Start is not concerned. I'm fed up as I already spent a lot of time in trying to fix a "bug" in Chromium in order to allow Java Web Start to work correctly anew in this browser and the plugin hang detector already kills applets taking "too much" time to load. I would like to go on working peacefully on JOGL 2.0, is it possible? Please let people choose whether or not they should install this plugin. Best regards and sorry for the noise, I have just worked since October 2006 on my first person shooter and I don't want anyone to ruin all my efforts.
My understandingof this attack is that it can be performed via normal browser behaviour. The attacking web site only needs to send known data to the Target web site from the browser. This can easily be done by making repeated requests for an image on the Target web site and altering the url parameters. The attacker then sniffs the encrypted SSL packets and does some analysis and eventually can work out the plain text. Java is only a convenient tool for the researchers.The researchers may have used a signed applet, which would still provide a valid proof for this attack.
(In reply to Dean from comment #34)
> My understandingof this attack is that it can be performed via normal
> browser behaviour. The attacking web site only needs to send known data to
> the Target web site from the browser. This can easily be done by making
> repeated requests for an image on the Target web site and altering the url
> parameters. The attacker then sniffs the encrypted SSL packets and does some
> analysis and eventually can work out the plain text. Java is only a
> convenient tool for the researchers.The researchers may have used a signed
> applet, which would still provide a valid proof for this attack.

Please see bug #665814 which contains some analysis of different vectors to the attack.
See Also: → CVE-2011-3389
In reply to Ivan, since your link supports my argument, I assume this bug will be discarded then. Hence Java applets will not be disabled in Firefox.
(In reply to Ian Melven :imelven from comment #35)
> (In reply to Dean from comment #34)
> > My understandingof this attack is that it can be performed via normal
> > browser behaviour. The attacking web site only needs to send known data to
> > the Target web site from the browser. This can easily be done by making
> > repeated requests for an image on the Target web site and altering the url
> > parameters. The attacker then sniffs the encrypted SSL packets and does some
> > analysis and eventually can work out the plain text. Java is only a
> > convenient tool for the researchers.The researchers may have used a signed
> > applet, which would still provide a valid proof for this attack.
> 
> Please see bug #665814 which contains some analysis of different vectors to
> the attack.

I have to agree with Dean in this matter. Unless I missed something, the researchers have demonstrated a WebSockets POC, not a Java-based POC. 

Furthermore, nobody can rule out a JavaScript XmlHttpRequest based attack.

Given that the key requirement for this exploit is high-bandwidth MITM access and that (as per the bug you posted) Chrome is working on a fix to their connection layer (effectively randomizing the IV), why would Mozilla choose to disable the Java plugin rather than focusing on a broader solution (and let Oracle work on the JSSE fix).
I kind of agree with Ryan. I am not sure why there's a discussion about Java here, the discussion should for now be limited to areas within FF team's control. Once a solution here is present, then we can revisit the potential issues with plugins. The approach taken here seems to suggest "Java is #1 (only?) potential attack vector, let's disable it" and also underlining that "Oracle refuses to fix Java" (is this the case?). Sorry to jump in.
An exploit involving Java makes use of a malicious applet.  I would think that anti-virus applications would detect and deal with such applets.  However, current queries at AVG and MalwareBytes both indicate this is not yet a capability for the products of either source.
Lets be clear. This exploit uses normal browser behaviour and normal Java applet behaviour. There is nothing wrong with the way the applet is behaving. The vulnerability is in the ssl/tls protocol itself. The ssl/tls implementations are not even wrong (according to the spec).

(In reply to David E. Ross from comment #39)
> An exploit involving Java makes use of a malicious applet.  I would think
> that anti-virus applications would detect and deal with such applets. 
> However, current queries at AVG and MalwareBytes both indicate this is not
> yet a capability for the products of either source.
Relying on 3rd-party, real-time, anti-malware products is not the answer.  Many users in the Windows and Mac worlds are liable to be running "free" versions of such products, which often do not contain the packet or connection scanning capabilities that the "paid-for" versions provide.  Among those who do have full-fledged anti-malware software installed, a sizeable proportion of those installations are likely to be broken or no longer maintained due to expired update subscriptions.  People who run Firefox on Linux/Some-Kind-of-BSD/UNIX workstations are likely to not use anti-malware software at all (at least not at the local workstation level), outside of extensions such as NoScript and/or FlashBlock.

In accordance with other suggestions provided above, I believe that the correct solution, at this time, is to force a "click-to-play" policy.  Java is a too heavily entrenched technology to do otherwise.  Case in point:  Citrix GoToAssist, WebEx, and a lot of other enterprise-grade remote assistance tools rely on Java to instantiate screen sharing and keyboard/mouse I/O interception. Furthermore, a statistically significant number of companies use Firefox instead of Internet Explorer [Windows] and/or Safari [OS X] as their preferred browser because of its broad-based website support and fine-grained security options.

However, as I understand it, the persons who demonstrated the vulnerability chose Java because it was an "easy" way (in a relative sense) to work around the same-origin policy, not because they thought it was the only way.

Another way to handle this problem would be to have the browser ask the website if TLS 1.1/1.2 is supported, and if not, fall back to TLS 1.0 and ask the user for permission to continue.  Of course, this would mean that Firefox would need to be modified to handle TLS 1.1/1.2 conversations (see Bug 565047 and Bug 480514).  However, if this method is used, the permission request dialog would need to be very carefully worded so as to not confuse or unduly alarm the user.

(In reply to David E. Ross from comment #39)
> An exploit involving Java makes use of a malicious applet.  I would think
> that anti-virus applications would detect and deal with such applets. 
> However, current queries at AVG and MalwareBytes both indicate this is not
> yet a capability for the products of either source.
K. Adams,

What you propose would expose a security problem known as a rollback attack. This type of issue is discussed in the TLS protocol. The TLS handshake protocol is supposed to prevent such attacks. However, this bug is the wrong one to discuss the TLS protocol implementation. If you want to discuss the NSS implementation, you can refer to https://bugzilla.mozilla.org/show_bug.cgi?id=665814 . For other implementations, only the specific vendors can discuss it.
(FYI, I do not speak for Oracle, and do not work on the Java plug-in implementation).
Brian,

(In reply to Brian Smith (:bsmith) from comment #17)
> (Nit: I mentioned Google mail in my initial comment. But, I believe that
> Google mail is not vulnerable to this bug in our default configuration
> because it prefers RC4 over other ciphers. But generally, servers are
> vulnerable.)

Servers are supposed to honor the cipher suites in the order that the client advertises them in the ClientHello - the first one is supposed to be the one the client prefers . If Google mail is using a different order, then it's violating the TLS spec. But perhaps they disabled all the CBC cipher suites on the server.
(In reply to Ryan Schipper from comment #37)
> why would Mozilla
> choose to disable the Java plugin rather than focusing on a broader solution
> (and let Oracle work on the JSSE fix).

This bug is not an exclusive response to the issue. There are other bugs dealing with other risk areas. I'm fairly confident in saying there is no implied 'focus' on this bug, aside from the mention by El Reg (a media focus does not mean a development focus!)

This is a bug proposing to block the Java Plugin as one part of, potentially, a series of mitigations. The fact that there are other methods around the same-origin policy does not mean there is not a problem with having a Java-based method for bypassing the same-origin policy. Discussion about other enabling vulnerabilities seems, to me, to have limited relevancy and risks missing the point there is an issue to be addressed here.
(In reply to Dean from comment #40)
> Lets be clear. This exploit uses normal browser behaviour and normal Java
> applet behaviour. There is nothing wrong with the way the applet is
> behaving.

The applet does not behave as it should in several ways: First, the applet is performing arbitrary connections to any specified server (the SOP bug) which allows to conduct this attack without being able to inject the applet into the TLS connection itself. It can instead be injected/load from any page. Secondly, the applet uses its own TLS engine for that purpose, which we cannot fix.

Please also note what Danny said, this bug is not the only response, it is one part of multiple responses. Bug 665814 is about fixing the TLS weakness in NSS itself which will prevent the attack with connections made by NSS. However, I am not aware of any exploits using the browser itself in a default configuration without plugins right now which makes the Java issue more critical. Of course it's possible that the attack can be adapted to work with XMLHttpRequest or the newer WebSockets standard. Note that the WebSockets mentioned in A.3 of the paper is WebSockets version 76, which has been superseeded by a new standard that has been in Firefox since version 5. This new WebSockets version obfuscates the plaintext (under the TLS layer) which makes it impossible for the client to control the plaintext that is encrypted.


(In reply to Dean from comment #34)
> My understanding of this attack is that it can be performed via normal browser behaviour. > The attacking web site only needs to send known data to the Target web site from the  
> browser. This can easily be done by making repeated requests for an image on the Target  
> web site and altering the url parameters.

This is not sufficient. If you read Section 5.3 of the paper closely, then you'll see that the image technique gets you the "chosen-boundary privilege", however, not the "blockwise
privilege" required for the attack.


I'd be very happy to discuss issues associated with BEAST further, it is a very interesting attack. However, I'd appreciate if we could move the discussion to some other place to keep this bug clean for the people working on this. I suggest IRC (e.g. irc.mozilla.org #security) or a newsgroup for that purpose.
does this only affect TLS 1.0 as java 7 has options for 1.1 and 1.2 although not default
Whiteboard: [sg:vector-high]
(In reply to Josh Aas (Mozilla Corporation) from comment #11)
> The file names for the Java plugins are:
> 
> Mac OS X: JavaPlugin2_NPAPI.plugin
> Windows: npjp2.dll
> Linux: libjavaplugin.so, libnpjp2.so, IcedTeaPlugin.so
> 

Thanks Josh. Could you provide the full information that's in about:plugins for these?

For example, on Mac it's:
    File: JavaPlugin2_NPAPI.plugin
    Version: 13.5.0
    Java Plug-In 2 for NPAPI Browsers

That will be a big help in coming up with the right syntax. Thanks.

(Please note that no decision has been made to block; I am merely gathering information.)
Assignee: nobody → fligtar
Got this for Windows 7 (64-bit):

File: npjp2.dll
Version: 6.0.260.3
Next Generation Java Plug-in 1.6.0_26 for Mozilla browsers
To know how users including companies will react to this blocking, see bug 629030 especially bug 629030 comment 17 and bug 629030 comment 59.

I think also that https://support.mozilla.com/en-US/kb/Firefox%20makes%20unrequested%20connections#w_extension-blocklist-updating will receive many visits from Java applet users and once extensions.blocklist.enabled is set to false, they'll never set it back to true later if Oracle releases a patch. In addition, they'll be expose to threats from blocked add-ons.

Other users will also stop using Firefox and migrate to other browsers that don't apply a Java blocking.
Either block it or don't.  It has been over a week and still no decision has been made just like most other bugs that are opened to block certain addons and plugins.  The decision process always takes way too long and does nothing to benefit the users.
Oracle is releasing an update to Java SE today to address this vulnerability, and we have decided not to block the vulnerable versions at this time.

For more information, please see our updated blog post:
http://blog.mozilla.com/security/2011/09/27/attack-against-tls-protected-communications/
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Oracle released fixes for their plugin, but what about the non-Oracle Java plugins? Do they even have access to the fixes yet? Are all of these effectively zero days against them?

I understand the concerns against blocking the Java Plugin, but I think we should come up with a mechanism that helps users upgrade their Java plugin right away and blocks old versions and/or implements some kind of other risk mitigations (e.g. IE-eqsue zones, click-to-play).

Oracle Java SE Critical Patch Update Advisory - October 2011:
http://www.oracle.com/technetwork/topics/security/javacpuoct2011-443431.html

Applet can execute arbitrary code: CVE-2011-3548, CVE-2011-3521, CVE-2011-3554, CVE-2011-3544

Heap overflow possibly leading to arbitrary code execution: CVE-2011-3551

SSL security issues: CVE-2011-3560 (was just wondering about this a couple weeks ago, for some reason), CVE-2011-3389 (BEAST)

DNS Cache poisoning via applet: CVE-2011-3552 (http://blog.watchfire.com/wfblog/2011/10/dns-poisoning-via-port-exhaustion.html)

Undisclosed: CVE-2011-3555, CVE-2011-3545, CVE-2011-3549, CVE-2011-3550, CVE-2011-3546, CVE-2011-3558 ("unspecified confidentiality impact"), CVE-2011-3561
(In reply to Brian Smith (:bsmith) from comment #52)
> I understand the concerns against blocking the Java Plugin, but I think we
> should come up with a mechanism that helps users upgrade their Java plugin
> right away and blocks old versions and/or implements some kind of other risk
> mitigations (e.g. IE-eqsue zones, click-to-play).
If Java SE 6 Update 28 and below are blocklisted, users that don't have admin rights on their computer (e.g. enterprise employees) can no longer use Java.
If Java SE 6 Update 28 and below are blocklisted, users that don't have admin rights on their computer (e.g. enterprise employees) can no longer use Java [until their IT department rolls out an update to secure their users.]

IT departments should be reacting responsibly and quickly to this vulnerability.
(In reply to chris hofmann from comment #54)
> IT departments should be reacting responsibly and quickly to this
> vulnerability.
What would be the reasonable delay between the release of Java SE6 update 29 (on October 18) and a blocklist of Java SE 6 update 28?
> What would be the reasonable delay

I think there are two ways to examine that question.

1) how long will it take for adminstrators to get the new version of java deployed?
and
2) how long will it take for attackers to start exploiting the holes in older versions.

Brian Krebs make the best case for moving quickly to protecting users inside and outside enterprise firewalls.

http://krebsonsecurity.com/2011/10/critical-java-update-fixes-20-flaws/

If you use Java, take some time to update the program now. According to a report released this month by Microsoft, the most commonly observed exploits in the first half of 2011 were those targeting Java flaws. The report also notes that Java exploits were responsible for between one-third and one-half of all exploits observed in each of the four most recent quarters.
These vulnerabilities will be exploitable during several years according to the update rate.
Version	Release date	Breakdown
 6.0.0.0	2006-12-11	0.1%
 6.0.100.33	2008-10-15	0.1%
 6.0.110.3	2008-12-03	0.1%
 6.0.120.4	2008-12-12	0.1%
 6.0.130.3		        0.4%
 6.0.140.8	2009-05-28	0.1%
 6.0.150.3	2009-08-04	0.2%
 6.0.160.1	2009-08-11	0.2%
 6.0.170.4	2009-11-24	0.4%
 6.0.180.7	2010-01-13	0.1%
 6.0.190.4	2010-03-30	0.1%
 6.0.200.2	2010-04-15	3.4%
 6.0.210.6		        0.6%
 6.0.210.7	2010-07-07	3.3%
 6.0.220.4	2010-10-12	6.3%
 6.0.230.5	2010-12-08	2.6%
 6.0.240.7	2011-02-15	8.2%
 6.0.250.6	2011-03-21	3.4%
 6.0.260.3	2011-06-07	52.1%
 6.0.270.3		        0.1%
 6.0.270.7	2011-08-16	13.6%
 6.0.290.11	2011-10-18	4.3%
As informing is better that blocklisting, especially for plugins with admin right issue, I filed bug 696339.
(In reply to Scoobidiver from comment #57)

very interesting data, what is the source please ? 

i agree that 696339 is a good approach, especially in the short term.
(In reply to Ian Melven :imelven from comment #58)
> very interesting data, what is the source please ? 
It's based on https://crash-analysis.mozilla.com/crash_analysis/20111020/20111020_Firefox_7.0.1-interesting-modules-with-versions.txt.gz (BIG file) where I looked for a crash signature correlated to npjp2.dll. Then I added all the crash numbers in the second column to have a total.
It's not a one-to-one matching because crashy users are over-represented but it's a good indication.
As there won't be a Whatsnew page for 8.0 (bug 696339), I think a recommended blocklist with a low severity (0, 1) that makes appear once the plugincheck page could be an alternative solution.
This solution might also have a good side effect for other outdated plugins like Flash because there's no Flash warning in localized Whatsnew pages (see bug 696348).
---------------------------------[ Triage Comment ]---------------------------------

We don't need to track this for a particular version/Firefox 6 as the plugin blocklist is delivered over the internet.

If we want to block for older Firefox versions is a different question but it is clear we should not track based on the way the tracking flag is meant to be used.
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.