744324 - Mitigation for recent Java vulnerabilities

Status: RESOLVED WONTFIX

(Camino Graveyard :: Plug-ins, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Content policy component

Firefox is in the process of blocklisting versions of the Java plug-in that suffer from the vulnerability that Flashback exploited (bug 741592).

We should consider doing the same thing (since we shipped 2.1 with Java off for everyone--yay!--this should affect a smaller number of users than otherwise).

However, 

1) I think the vulnerability is in Java, not the plug-in itself, so for users with the JEP, we can't use the plug-in version as a proxy for fixed Java, and thus we can't really determine whether to disable the JEP,

2) Bug 701968, and

3) we still support 10.5 and 10.4, which have permanently-vulnerable versions of Java; it would be nice if we were able to allow users of those OSes who needed to use Java to still use the latest versions of Java on sites where they needed it, rather than just killing it entirely (similar to how we forced Flashblock on on PPC once Intel dropped support for PPC; users could whitelist trusted sites and keep Flash blocked everywhere else).

For problematic item #3, I tried patching Flashblock to block Java, but a) it was never able to block stand-alone <applet> instances, and b) for <applet>-inside-<object>, it only overlaid the placeholder on top of the already-running applet.  The <applet> code path is apparently different enough from regular plug-ins that Flashblock doesn't get loaded early enough.

There is another solution, however: Gecko content policies.  I have cobbled together from sample code a JS XPCOM component that implements a content policy that blocks all Java applets from loading unless their containing page or source files match a list of domain-type values from a Gecko pref.  (Presumably the same could be done in C++/Obj-C, but, as expected with Gecko, there really weren't any examples.)

The component (attached, and the latest version is also at http://hg.mozilla.org/users/alqahira_ardisson.org/misc/file/tip/aoJavaPolicy.js ) is rather rough, and as usual I don't know how/where to do all the GeckXPCOMy things I'd like to do.  We could conceivably ship something like this, with the current checks wrapped in a pref check to see if "Java blocking" was enabled; we could then set the "Java blocking" pref at startup in migration code for users on 10.4 and 10.5, like we did for Flashblock on PPC.

I don't know if we want to pursue any of this mitigation or not; maybe shipping 2.1 with Java off for everyone is good enough and users on 10.4 and 10.5 who need Java need to come upon a solution on their own (turning off Java in prefs except when using it)?

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: C++/Obj-C content policy

Here's a C++/Obj-C implementation.  It was a royal pain in the @#$#@, partly because Gecko really likes components to be (part of) modules, and partly because I was accidentally breaking on JavaContentPolicy::ShouldProcess, which never gets called (it doesn't get called in embedding/browser/webBrowser/nsWebBrowserContentPolicy.cpp, either, so I guess that method is just broken).

This implementation has a bit better logic flow than the JS component and it also checks a pref to see if it should even be active, but it still shares some of the same flaws of the JS component: namely that (both!) prefs are checked on every single request.

Adding the pref change notification stuff isn't hard, but I'm unsure how to do a one-time set-up of the initial pref values.

Oh, hmm, maybe I just need to use NS_GENERIC_FACTORY_CONSTRUCTOR_INIT instead of NS_GENERIC_FACTORY_CONSTRUCTOR and have the init method do the pref value set-up.  Maybe(?) that will also let me move the content-policy category registration out of CHBrowserService (component registration from AppComponents is weird; they don't end up in compreg.dat, so it's hard to say how that works…).

Then the only other thing that would be needed is to write the code to set the java-blocking pref on for 10.4 and 10.5 and whatever situations we want to use it (but definitely for 10.4 and 10.5).

So, I'm not sure what I hate more, XPCOM-in-JS or XPCOM-in-C++, but now there's definitely some progress.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Iteration, v0.6

So, as the good times keep rolling… :P

If I use NS_GENERIC_FACTORY_CONSTRUCTOR_INIT, I can do stuff in init, which is nice.

However, if I move the content-policy category registration out of CHBrowserService, then JavaContentPolicy::Init never gets called(!).  So I kept the category registration in all its ugliness in CHBrowserService.

I have the pref-reading in Init set up, mostly.  For reasons that are not clear, I need to retain the whitelist (mWhitelist) NSString, or I end up with random objects when I check it in JCP::shouldLoad, though I don't seem to need to retain the "policy enabled" (mPolicyEnabled) BOOL?!

Stuart, two questions so far:

1) What's the best way to handle retaining the whitelist (and should I retain the mPolicyEnabled anyway?)?

2) For the pref changed notification and pref-twiddling, I think what's required is what you described in bug 322845 comment 11.  Can you explain that to me in a little more concrete terms; it's still a bit too real-programmer-y-ese for me to wrap my head around.  And/or do we have any examples in the tree I can study?

Comment 4

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/