Closed Bug 786507 Opened 12 years ago Closed 12 years ago

create hotfix to soft-block vulnerable Java

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: Gavin, Assigned: Gavin)

Details

(Keywords: sec-critical)

Attachments

(1 file)

WIP
4.35 KB, patch
Details | Diff | Splinter Review 
Java is vulnerable to a 0day exploit that is harming users. Our blocklist options aren't great, and so mcoates has proposed we address the threat using a hot-fix add-on that blocks Java:

From e-mail:

> The objective:
> Develop an addon which is deployed via addon hotfix that:
> 1. Disables Java by default (for vulnerable versions)
> 2. When a user encounters a page which contains Java then an
> infobar is
> prominently displayed which alerts the user that Java has been
> disabled
> for their security. A message similar to the following is
> displayed:
> If you need to access this page and trust it, Click here to enable
> reload the page with Java enabled
> (we can work on the wording, but that's the idea)
> 3. Clicking on a button in the info bar causes the page to reload
> with
> Java enabled
> 4. Java is only enabled on this specific page. Any other page or
> domain
> would start over at step 1
> (4b -  if #4 is not feasible and Java is then enabled for all sites
> it is still a win overall)
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #0)
> > 1. Disables Java by default (for vulnerable versions)

We'll need a list of "vulnerable versions".

> > (4b -  if #4 is not feasible and Java is then enabled for all sites
> > it is still a win overall)

I think quick turnaround on an add-on with site-specific enabling will be too difficult, but I'm open for suggestions on implementation strategy.
Some other questions we'll need to answer:
- How should the hotfix
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #2)
> Some other questions we'll need to answer:
> - How should the hotfix

Sorry, entered too early:

- How/when should the hotfix disable itself? Presumably we'll want it to uninstall itself in Firefox versions > 15, and not be effective for Java versions greater than the vulnerable version?
I'm not sure what approach is best for showing the info bar. Detecting when a page attempts to use the disabled plugin is a bit tricky - we could monkey patch every browser window's PluginDisabled handler, I guess?
I guess we could just add our own PluginDisabled handler, but we'll need to do it for all windows.
Attached patch WIP — — Splinter Review 
Here's a basic framework for what the hotfix add-on could look like. Still a lot of questions to answer, but I need to leave.

(This is a patch on top of https://hg.mozilla.org/users/dtownsend_mozilla.com/hotfixes/.)
We should build this same code directly into the browser in Fx16 and make the hotfix Fx15-only. Are hotfix addons shown in the addons manager UI? If not, can we just set maxversion=15.* and be done with it?

Per email, we shouldn't focus on per-site enablement at this time: we'll get that ability in Fx17 (I'll make sure there is a bug). But should we perhaps recommend noscript to users who decide to enable Java, since that does have current per-site controls?
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #7)
> Are hotfix addons shown in the addons manager UI?

Yes, it is shown in the list of extensions and can be disabled or uninstalled.

Note that there can only be one hotfix extension installed because it uses a specific addon ID.  If we want to have multiple hotfixes, they need to be combined in one XPI or target different platforms and versions then let AMO serve the applicable one.
Is the previous hotfix (bug 741004) still being served? If so, can we just replace it with this new one, given that we're well past 13 now and most people who will update will have updated already?
Marking sec-critical as there are exploits in the wild and mitigation is critical.
Keywords: sec-critical
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #9)
> Is the previous hotfix (bug 741004) still being served? If so, can we just
> replace it with this new one, given that we're well past 13 now and most
> people who will update will have updated already?

Yes it is and we could discontinue it but we are also creating a new one in bug 774509 for OS X 10.5 EOL so we should keep it in mind.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #1)
> (In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment
> #0)
> > > 1. Disables Java by default (for vulnerable versions)
> 
> We'll need a list of "vulnerable versions".

Java 7 (version 1.7, updates 0 through 6)
Assignee: nobody → gavin.sharp
(In reply to Michael Coates [:mcoates] from comment #12)
> Java 7 (version 1.7, updates 0 through 6)

I think I'll need some QA help to figure out how that maps to the versions we see programmatically, i.e. the versions that show up in about:addons' plugin tab. We'll need to make sure we get data from all relevant platforms, as well.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #13)
> I think I'll need some QA help to figure out how that maps to the versions
> we see programmatically

This has already been done to a certain extent in bug 780717.

Linux:
Java(TM) Plug-in 1.7.0_05
    File: libnpjp2.so
    Version: 
    Java plug-in for NPAPI-based browsers.

Java(TM) Plug-in 1.7.0_04
    File: libnpjp2.so
    Version: 
    Java plug-in for NPAPI-based browsers.

Java(TM) Plug-in 1.7.0_03
    File: libnpjp2.so
    Version: 
    The next generation Java plug-in for Mozilla browsers.

Let me know if you need more then this.
Windows:
Java(TM) Platform SE 7
    File: npjp2.dll
    Version: 10.0.0.147
    Next Generation Java Plug-in 10.0.0 for Mozilla browsers

Java(TM) Platform SE 7 U1
    File: npjp2.dll
    Version: 10.1.0.8
    Next Generation Java Plug-in 10.1.0 for Mozilla browsers

Java(TM) Platform SE 7 U2
    File: npjp2.dll
    Version: 10.2.0.13
    Next Generation Java Plug-in 10.2.0 for Mozilla browsers

Java(TM) Platform SE 7 U3
    File: npjp2.dll
    Version: 10.3.1.255
    Next Generation Java Plug-in 10.3.1 for Mozilla browsers

Java(TM) Platform SE 7 U4
    File: npjp2.dll
    Version: 10.4.1.255
    Next Generation Java Plug-in 10.4.1 for Mozilla browsers

Java(TM) Platform SE 7 U5
    File: npjp2.dll
    Version: 10.5.1.255
    Next Generation Java Plug-in 10.5.1 for Mozilla browsers
Sorry for the bug cruft, but also still TBD is what the minimum targeted version will be for this add-on. Additionally, we should aim to create two add-ons - one to test with 16/17/18 audiences, and the other to release to {minimum_ver} and up.
QA Contact: anthony.s.hughes
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #14)
> This has already been done to a certain extent in bug 780717.

Probably best to collect this data on an etherpad or something rather than in this bug, but that list looks incomplete... e.g. are _03, _04, and _05 really the only Linux versions we care about, or are there others? What about Mac? Can we confirm this with any contacts at Oracle?
It's not a complete list, obviously. It was just what I copied and pasted from the referenced bug. If you want every single Java version's string from Java 7 through Java 7u6 on win32, mac, and linux, I can do that. It will take me some time though. Please let me know if this is what you want.
Opening bug - blog post also updated for those looking for a summary of our intended approach

https://blog.mozilla.org/security/2012/08/28/protecting-users-against-java-security-vulnerability/
Group: core-security
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #17)
> It's not a complete list, obviously. It was just what I copied and pasted
> from the referenced bug. If you want every single Java version's string from
> Java 7 through Java 7u6 on win32, mac, and linux, I can do that. It will
> take me some time though. Please let me know if this is what you want.

I think this is what we want, but someone more familiar with the details of the exploit should confirm. I can write you a small restartless add-on that collects the data I need in the right format, if that works for you?
> I can write you a small restartless add-on that collects
> the data I need in the right format
I assume the format you need is what I posted in comment 14 (ie. strings from about:plugins). Please let me know if there is some other format you require.

I'm not sure a restartless add-on will help at all since the majority of the legwork is downloading/installing/uninstalling the various Java versions. Thanks for the offer though.

I'll wait to hear back about the scope of the testing required (ie. Java versions).
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #20)
> I assume the format you need is what I posted in comment 14 (ie. strings
> from about:plugins).

OK, that will work.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #5)
> I guess we could just add our own PluginDisabled handler, but we'll need to
> do it for all windows.

Ran into a snag here - there's no way to get the exact plugin from a PluginDisabled handler (which is an event fired against the plugin element), as far as I can tell. I just know that someone attempted to load a disabled plugin, without knowing for sure that it was a Java plugin.
I managed to get *most* of the Java 7 strings you require, Gavin. I've put them in a QA wiki page for posterity:

https://wiki.mozilla.org/QA/Plugins/Java#Java_7

I encountered a couple of snags with Mac, resulting in me only being able to get the 7u6 strings:
 * the only way I could get a Java 7 JRE installed was by installing the JDK
 * only JDK 7u6, 7u5, 7u4 are available for download, the rest appear to be missing
 * installing JDK 7u6, 7u5, and 7u4 all resulted in JRE 7u6 being used by the browser
I tried several documented methods to get other JRE versions registering in Firefox but no matter what it kept using JRE 7u6.

I know this is less then ideal but hopefully it is enough to get started. Please let me know if there is more I can do at this stage.
FYI, the string

Displays Java applet content, or a placeholder if Java is not installed.

is localized to 

Zeigt Java-Applet-Inhalte an oder einen Platzhalter, falls Java nicht installiert ist.

on my german Mac.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #22)
> Ran into a snag here - there's no way to get the exact plugin from a
> PluginDisabled handler (which is an event fired against the plugin element),
> as far as I can tell. I just know that someone attempted to load a disabled
> plugin, without knowing for sure that it was a Java plugin.

I can't see a way to get the plugin tag from scripts right now, but you could get the plugin info:
http://mxr.mozilla.org/mozilla-release/source/browser/base/content/browser-plugins.js#6
... and then run through the tags from the PluginHost to find the one(s) which handle(s) that mimetype, then check if it matches the mentioned name & version patterns.
(In reply to Axel Hecht [:Pike] from comment #24)

I don't think we'll need to rely on plug-in descriptions, so this shouldn't be an issue.
(In reply to Georg Fritzsche [:gfritzsche] from comment #25)
> I can't see a way to get the plugin tag from scripts right now, but you
> could get the plugin info:
> http://mxr.mozilla.org/mozilla-release/source/browser/base/content/browser-
> plugins.js#6
> ... and then run through the tags from the PluginHost to find the one(s)
> which handle(s) that mimetype, then check if it matches the mentioned name &
> version patterns.

Good idea! I think this seems like the most robust solution so far.
FYI, Oracle has released an out of cycle update (Java 7 Update 7) that appears to fix the vulnerability used by the exploit recently added to Metasploit.
(In reply to Ian Melven :imelven from comment #28)
> FYI, Oracle has released an out of cycle update (Java 7 Update 7) that
> appears to fix the vulnerability used by the exploit recently added to
> Metasploit.

Does that mean we can just proceed with a block for Java 7u6 and earlier?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #29)
> (In reply to Ian Melven :imelven from comment #28)
> > FYI, Oracle has released an out of cycle update (Java 7 Update 7) that
> > appears to fix the vulnerability used by the exploit recently added to
> > Metasploit.
> 
> Does that mean we can just proceed with a block for Java 7u6 and earlier?

Yvan filed bug 787136 for a soft block to do just that.
(In reply to Ian Melven :imelven from comment #30)
> (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #29)
> > (In reply to Ian Melven :imelven from comment #28)
> > > FYI, Oracle has released an out of cycle update (Java 7 Update 7) that
> > > appears to fix the vulnerability used by the exploit recently added to
> > > Metasploit.
> > 
> > Does that mean we can just proceed with a block for Java 7u6 and earlier?
> 
> Yvan filed bug 787136 for a soft block to do just that.

My mistake, bug 787136 is for updating plugin check. I'm not aware of a soft block bug yet.
We already had one on file for this before we started moving forward with the hotfix. See bug 785837. It was staged and tested on August 28.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #27)
> (In reply to Georg Fritzsche [:gfritzsche] from comment #25)
> > I can't see a way to get the plugin tag from scripts right now, but you
> > could get the plugin info:
> > http://mxr.mozilla.org/mozilla-release/source/browser/base/content/browser-
> > plugins.js#6
> > ... and then run through the tags from the PluginHost to find the one(s)
> > which handle(s) that mimetype, then check if it matches the mentioned name &
> > version patterns.
> 
> Good idea! I think this seems like the most robust solution so far.

Per IRC it turned out that this approach also has problems with access from scripts. Alternative suggestion would be to use the approach of "about:plugins":
http://mxr.mozilla.org/mozilla-release/source/toolkit/content/plugins.html?force=1#75
Ah, yeah, that'd work! But...

Per discussion on release-drivers, we decided not to go down this route.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: