Last Comment Bug 589041 - (CVE-2010-3775) Java security bypass from LiveConnect loaded via META Refresh "data:" URL
(CVE-2010-3775)
: Java security bypass from LiveConnect loaded via META Refresh "data:" URL
Status: RESOLVED FIXED
[sg:critical][critsmash:investigating...
:
Product: Core
Classification: Components
Component: Security (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 598453 611897 611910
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-19 20:11 PDT by Gregory Fleischer
Modified: 2014-09-04 09:40 PDT (History)
17 users (show)
rforbes: sec‑bounty+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
.13+
.13-fixed
.16+
.16-fixed


Attachments

Description Gregory Fleischer 2010-08-19 20:11:40 PDT
The Java security policy may be bypassed when LiveConnect script is loaded via a "data:" URL using a META Refresh.

The basic construct would appear as:

<meta http-equiv="Refresh" content="0,data:text/html,<html><body><script>alert(self.java);</script></body></html>">

This script will run with under a security policy of "moz-nullprincipal:{xxxx-xxxx-xxxx}".  It appears that the plugin logic may not be correctly accounting for this.

The severity of this issue seems highly dependent on browser, JRE version, plugin and platform.  

Tested with Apple Java (MRJ/JEP plugin):

Firefox 3.6 - Mac OS X: read files, connect sockets, execute programs
Firefox 3.5 - Mac OS X: read files, connect sockets, execute programs

Tested using Oracle/Sun JavaSE:

Firefox 3.6 - Windows - JRE 1.6: crash JVM
Firefox 3.5 - Windows - JRE 1.6: crash JVM
Firefox 3.5 - Windows - JRE 1.5: read files

Firefox 3.6 - Linux - JRE 1.6: crash JVM
Firefox 3.5 - Linux - JRE 1.6: read files
Firefox 3.5 - Linux - JRE 1.5: read files

Tested with OpenJDK: 

Firefox 3.6 - Linux - IcedTea6: no bypasses observed


Note: also tested with latest nightly (20100819) 3.6 and 3.5 builds with same results.
Comment 1 Gregory Fleischer 2010-08-19 20:13:48 PDT
Created attachment 467648 [details]
Test cases

Test cases for different scenarios:
 - read a local file
 - read URL contents
 - connect a Socket
 - launch a process
Comment 2 Daniel Veditz [:dveditz] 2010-08-20 20:08:12 PDT
I'm kind of OK with crashing the JVM on Windows and Linux, or at least I'm more
concerned about Mac. Stephen: can we catch this in the JEP before handing it
off to Apple's JVM?
Comment 3 Steven Michaud [:smichaud] (Retired) 2010-08-21 10:45:12 PDT
> Tested with Apple Java (MRJ/JEP plugin):
>
> Firefox 3.6 - Mac OS X: read files, connect sockets, execute programs
> Firefox 3.5 - Mac OS X: read files, connect sockets, execute programs

I've confirmed this on both OS X 10.5.8 and OS X 10.6.4 :-(

Now to find out whose fault it is, and what I might be able to do
about it.

One consolation (for me) is that the new JEP that I'm currently
working on deals correctly with all these testcases -- it catches all
the security violations and aborts the offending JavaScript command.
Nothing crashes -- the browser or the JVM.  But the new JEP isn't
going to be ready soon enough (for a general release) to deal with
this problem.
Comment 4 Steven Michaud [:smichaud] (Retired) 2010-08-21 14:29:09 PDT
> This script will run with under a security policy of
> "moz-nullprincipal:{xxxx-xxxx-xxxx}".

In other words, the script's subject principal (an nsIPrincipal
object) has its 'origin' set to "moz-nullprincipal:{xxxx-xxxx-xxxx}".

> Now to find out whose fault it is, and what I might be able to do
> about it.

This appears to be a Mozilla bug.  The doc on nsIPrincipal's origin
attribute (in nsIPrincipal.idl) says:

  The origin of this principal's codebase URI.
  An origin is defined as: scheme + host + port.

This contract is violated by setting the origin to
"moz-nullprincipal:{xxxx-xxxx-xxxx}".

But the JEP's behavior when encountering an ill-formed origin is also
rather buggy:  It assumes that an nsIPrincipal object with an
ill-formed origin (or no origin at all) is the system principal.

It'd be easy enough for me to change the JEP so that it refuses to do
JavaScript-to-Java Liveconnect whenever it encounters an ill-formed
origin (one that isn't a plain-vanilla URL -- one that causes the Java
URL(String) constructor to choke).  This would mean that non-applet
JavaScript-to-Java Liveconnect never runs with special privileges.
But that's probably how things should be (and how they already are in
the "new JEP" -- which will eventually become JEP 0.9.8, or possibly
1.0).

I should be able to create and test a new version (JEP 0.9.7.4) in the
next few days -- one whose only change is what I described in the
previous paragraph.  But it's probably best to postpone its formal
release (its availability at http://javaplugin.sourceforge.net/) until
new versions of FF are released (3.6.10 and 3.5.13) that bundle JEP
0.9.7.4.

What do people think about this?
Comment 5 Steven Michaud [:smichaud] (Retired) 2010-08-21 18:10:34 PDT
(Following up comment #4)

> It'd be easy enough for me to change the JEP so that it refuses to
> do JavaScript-to-Java Liveconnect whenever it encounters an
> ill-formed origin (one that isn't a plain-vanilla URL -- one that
> causes the Java URL(String) constructor to choke).  This would mean
> that non-applet JavaScript-to-Java Liveconnect never runs with
> special privileges.

It'd also mean that JavaScript-to-Java Liveconnect wouldn't work *at
all* when the current script's subject principal had a
wierd/ill-formed origin.  My feeling is that this would be no great
loss.  But others may think/know differently.
Comment 6 Benjamin Smedberg [:bsmedberg] 2010-08-24 09:01:57 PDT
This only affects old-style java plugins (using liveconnect), not npruntime scripting, right? In which case, this bug doesn't affect trunk, only 1.9.2 on branch and 1.9.1 on all platforms.
Comment 7 Steven Michaud [:smichaud] (Retired) 2010-08-24 09:44:04 PDT
> This only affects old-style java plugins (using liveconnect), not
> npruntime scripting, right?

By the way, "liveconnect" here means the old browser-side Liveconnect
support in Mozilla, which together with the old OJI support allowed
Sun's old OJI plugin to do Java.  It doesn't refer to Liveconnect in
general, which is still supported (on the trunk and branches) using
npruntime (and Sun/Oracle's new Java Plugin2 plugin).

That said, I believe this is correct.  I've only seen the exploits
work with the JEP on OS X (which currently uses both OJI and
browser-side Liveconnect).  I only see the error message "No Java? No
LiveConnect?" running this bug's testcases on Windows XP and Linux
with Sun/Oracle's Java 6, using any current version of FF (FF 3.5.X,
FF 3.6.X, FF 4pre -- all of which use Java Plugin2 on Windows and
Linux, via npruntime, when it's available)

Gregory, can you explain why I don't see any crashes on Windows or
Linux?
Comment 8 Steven Michaud [:smichaud] (Retired) 2010-08-24 10:07:06 PDT
Just to make it clear, npruntime is an extension of NPAPI, used to script plugins.
Comment 9 Daniel Veditz [:dveditz] 2010-08-24 13:49:32 PDT
part of the confusion here is that inside Mozilla "LiveConnect" refers to a particular technology, that has now been replaced. Outside Mozilla "LiveConnect" means "running Java without an <applet>" -- a feature now supported in multiple browsers.
Comment 10 Steven Michaud [:smichaud] (Retired) 2010-08-24 14:16:23 PDT
Actually, the most common usage of "LiveConnect" refers to
communication between Java and JavaScript.  There are two kinds --
JavaScript-to-Java LiveConnect and Java-to-JavaScript LiveConnect.

And there are two kinds of JavaScript-to-Java LiveConnect -- one that
scripts a Java applet (calls its methods or accesses its fields), and
another that directly creates Java objects and scripts them (calls
their methods or accesses their fields).  Only the latter is "running
Java without an <applet>".
Comment 11 Steven Michaud [:smichaud] (Retired) 2010-08-24 14:19:51 PDT
Forgot to mention:

As far as I know, only Mozilla still supports "running Java without an
applet".  Neither Safari nor Opera support it (on OS X).  I don't
think Chrome does, either.
Comment 12 Steven Michaud [:smichaud] (Retired) 2010-08-24 14:22:30 PDT
And to run this bug's testcases, a browser needs to support "running
Java without an applet".
Comment 13 Gregory Fleischer 2010-08-24 17:48:52 PDT
(In reply to comment #7)

> Gregory, can you explain why I don't see any crashes on Windows or
> Linux?

Don't know.

Here is what I observed:

1) open site that loads Java applet
2) in another tab, run test case code
3) original Java applet no longer functions

For example,

1) open http://nist.time.gov/timezone.cgi?UTC/s/0/java 
   - should start Java applet with time
2) in another tab, run test case
3) return to original tab, Java applet no longer functions

The same can be observed if the Java console is launched prior to running test cases.

On Windows with Java tracing & logging turned on, the last message trace is something like:

JVM heartbeat .. Exception, send ts: 363387102831, now ts: 363397104819, dT 10001988
Comment 14 Steven Michaud [:smichaud] (Retired) 2010-08-25 13:49:42 PDT
(In reply to comment #13)

OK, now I see what you mean.  Thanks!!

I was naively looking for the browser to crash.  But it's only the
"client" process of Java Plugin2 that crashes.  (Testing on Windows,
this happed in FF 3.6.8 and today's Minefield nightly.)

But I have no idea *why* Java Plugin2 crashes.

I looked through fairly recent source code for Java Plugin2, and
couldn't find any place where it tries to get an nsIPrincipal object
from the browser.

There *is* code in Java Plugin2 to use XPCOM to get proxy information,
to get and set cookies, and to get auth information for a page that
uses basic HTTP auth.  But it's only used if the browser doesn't
support NPAPI calls that provide the same information.  And FF has
supported all these NPAPI calls since FF 3.5.

So this bug's testcase *does* effect FF4pre on Windows and Linux.  But
it's not at all clear we're seeing the same bug on Windows and Linux
as we are on OS X.
Comment 15 Steven Michaud [:smichaud] (Retired) 2010-08-25 13:53:29 PDT
> But it's not at all clear we're seeing the same bug on Windows and
> Linux as we are on OS X.

At least when Java Plugin2 is in use (which is only available with
Java 6).
Comment 16 Steven Michaud [:smichaud] (Retired) 2010-08-25 14:08:34 PDT
The same crashes happen in FF (all current versions, using this bug's
testcases) when it uses Java Plugin2 on OS X (10.5.8 and 10.6.4).
Comment 17 Steven Michaud [:smichaud] (Retired) 2010-08-26 09:39:34 PDT
Created attachment 469495 [details]
Testcases loaded "normally" (not via META Refresh "data:" URL)

Here's Gregory's set of testcases, altered to load each testcase
"normally".  It has no problems in either FF+JEP (on OS X) or
FF+Java-Plugin2 (on Windows, Linux and OS X) -- all access violations
are caught (and aborted), and there are no crashes.

> This script will run with under a security policy of
> "moz-nullprincipal:{xxxx-xxxx-xxxx}".  It appears that the plugin
> logic may not be correctly accounting for this.

This is certainly true with FF+JEP.  But I can't believe it explains
the Java client process crashes with Java Plugin2 -- I can find no way
that the "security policy" gets passed to Java Plugin2.

I'm also pretty sure the Java Plugin2 client process crashes are
entirely the fault of Java Plugin2 -- the new JEP (what will become
JEP 0.9.8 or 1.0), which also uses NPAPI and npruntime, has no
problems with the original testcase in any current version of FF.

So this bug appears to really be two different bugs:

1) A security hole in FF+JEP (on OS X) that is partly a bug in the
   browser and partly a bug in the JEP.

2) A crash bug in Java Plugin2, which only happens in browsers that
   support LiveConnect without applets.
Comment 18 Steven Michaud [:smichaud] (Retired) 2010-09-10 18:54:31 PDT
(Following up comment #4)

> I should be able to create and test a new version (JEP 0.9.7.4) in
> the next few days -- one whose only change is what I described in
> the previous paragraph.  But it's probably best to postpone its
> formal release (its availability at
> http://javaplugin.sourceforge.net/) until new versions of FF are
> released (3.6.10 and 3.5.13) that bundle JEP 0.9.7.4.
>
> What do people think about this?

Not having received any responses to my question, I went ahead and
created a JEP 0.9.7.4 -- though (as promised) I haven't yet released
it.

It works around this bug, and also makes two other very small changes
to fix annoying problems.  I've tested all my changes -- but, as I
said, they didn't require much testing, because they're so small.

> It'd be easy enough for me to change the JEP so that it refuses to
> do JavaScript-to-Java Liveconnect whenever it encounters an
> ill-formed origin (one that isn't a plain-vanilla URL -- one that
> causes the Java URL(String) constructor to choke).  This would mean
> that non-applet JavaScript-to-Java Liveconnect never runs with
> special privileges.  But that's probably how things should be (and
> how they already are in the "new JEP" -- which will eventually
> become JEP 0.9.8, or possibly 1.0).

I ended up with a slightly different fix.  JEP 0.9.7.4 refuses to do
JavaScript-to-Java LiveConnect whenever it encounters a subject
principal *other than the system principal* with an ill-formed origin.
Since there's an nsIScriptSecurityManager::GetSystemPrincipal()
method, it's easy to check if the current script's principal is the
system principal, and if so let the JavaScript-to-Java LiveConnect
call proceed with enhanced privileges.

I could probably release JEP 0.9.7.4 without letting the cat out of
the bag.  My code changes (and comments) don't give any description of
the attack vector -- any more so than do the comments I've made in
this bug.  I suspect even a knowledgeable person would have difficulty
constructing an attack, knowing only (for example) what I said in the
previous paragraph -- though Gregory may be able to correct me on
this.

But even so, it's better to be cautious.  So I'm not going to release
JEP 0.9.7.4 until I hear from people like Dan Veditz.

This will be inconvenient for testers:  The JEP 0.9.7.4 distro is
probably too large to post here, and I don't have anywhere else to
post it that isn't publicly accessible.

I'll be in Mountain View next week, and will leave copies there for
people to test with.  But that doesn't take care of all interested
parties.  Gregory, would you like me to email you a copy?  The distro
(a zip file) is about 4MB.
Comment 19 Daniel Veditz [:dveditz] 2010-09-14 13:55:00 PDT
Let's figure this one out this week while Steven is here.
Comment 20 Steven Michaud [:smichaud] (Retired) 2010-09-21 14:32:35 PDT
I've opened bug 598453 to get JEP 0.9.7.4 on the branches.
Comment 21 Steven Michaud [:smichaud] (Retired) 2010-09-24 14:07:39 PDT
The Mac-specific part of this bug has now been fixed by landing JEP 0.9.7.4 on the branches (in bug 598453).  Since this bug appears to only have security implications on OS X, I've marked the whole bug fixed.

The new JEP should appear in tomorrow's nightlies.  Please test them!
Comment 22 Damon Sicore (:damons) 2010-09-28 13:34:17 PDT
Steven, in Comment 21 above, you said you've marked the whole bug fixed, but that hasn't happened.  Are you waiting for something here?
Comment 23 Steven Michaud [:smichaud] (Retired) 2010-09-28 13:38:30 PDT
Oops.  I marked it "status 1.9.2.11-fixed" and "status 1.9.1.14-fixed" without marking the whole bug fixed.  I didn't mean to do that.
Comment 24 Gregory Fleischer 2010-09-28 14:32:40 PDT
What about the non-OS X ones using Oracle/Sun JavaSE:

Firefox 3.5 - Windows - JRE 1.5: read files

Firefox 3.5 - Linux - JRE 1.6: read files
Firefox 3.5 - Linux - JRE 1.5: read files

I can retest, but was there any changes to address them?  Or are they no longer a concern?
Comment 25 Steven Michaud [:smichaud] (Retired) 2010-09-28 15:31:36 PDT
(In reply to comment #24)

See particularly comment #14 and comment #17.

It's my conclusion, based on what evidence I can find, that the
crashes in Java Plugin2's client process are unrelated to the security
problem in OJI and the JEP on OS X.  But I'm not sure I've covered all
the bases WRT these crashes -- in large part because I don't really
have the tools to debug crashes in other processes than the browser's
main process, particularly on Windows and Linux.

If someone (you or someone else) can do this sort of testing, and
therefore go beyond what I've already done, that would be very useful.

> Firefox 3.5 - Windows - JRE 1.5: read files

> Firefox 3.5 - Linux - JRE 1.6: read files
> Firefox 3.5 - Linux - JRE 1.5: read files

I wasn't able to reproduce any of the security problems you reported
using Sun's Java Plugin2 and recent releases of FF 3.5.X (the client
process always just crashed).

Note that we're not interested in results using OJI and older versions
of Sun's Java Plugin on platforms other than OS X (e.g. Windows and
Linux):  As far as I know, all current versions of Firefox (FF 3.5.X
and up) refuse to use the old Sun OJI plugin on platforms other than
OS X.

If I'm wrong about FF 3.5 (in other words if I'm wrong that current
releases of FF 3.5 refuse to use the old Sun OJI plugin on Windows and
Linux), someone please speak up!!
Comment 26 Steven Michaud [:smichaud] (Retired) 2010-09-28 16:07:47 PDT
(Following up comment #25)

In other words, Gregory, please re-run your tests with FF 3.5.13.
Comment 27 Steven Michaud [:smichaud] (Retired) 2010-09-28 16:49:41 PDT
> If I'm wrong about FF 3.5 (in other words if I'm wrong that current
> releases of FF 3.5 refuse to use the old Sun OJI plugin on Windows
> and Linux), someone please speak up!!

I found a Windows system with J2SE 5.0 Update 17 on which I could
test, and it turns out I *am* wrong -- on it, using FF 3.5.13, the
first of Gregory's testcases "works" (it's able to read the contents
of C:\BOOT.INI).  (FF 3.6.10 does refuse to use J2SE 5.0.)

So this bug *isn't* fixed on the 1.9.1 branch (in FF 3.5.X) except on
the Mac.

I suggest we fix this by backporting the code that stops FF 3.6 and
above from using Sun's old OJI Java plugin (that only uses Java
Plugin2).  I'm not familiar with that code, so someone else will need
to take care of this.
Comment 28 christian 2010-09-28 17:06:39 PDT
Looks like this will likely slip out of 1.9.1.14 then. dveditz, is it ok fixing this on 1.9.2.11 and not disclosing until it is 100% fixed on 1.9.1?
Comment 29 Steven Michaud [:smichaud] (Retired) 2010-09-28 18:08:18 PDT
> I suggest we fix this by backporting the code that stops FF 3.6 and
> above from using Sun's old OJI Java plugin (that only uses Java
> Plugin2).

I'm referring to the patch for bug 497423.
Comment 30 Gregory Fleischer 2010-09-28 20:06:14 PDT
(In reply to comment #26)
> (Following up comment #25)
> 
> In other words, Gregory, please re-run your tests with FF 3.5.13.

Re-tested on Linux and was able to duplicate issue with reading any user accessible file.

Versions:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.13) Gecko/20100914 Firefox/3.5.13

Java Plug-in 1.5.0_22
Using JRE version 1.5.0_22 Java HotSpot(TM) Client VM

Java Plug-in 1.6.0_21
Using JRE version 1.6.0_21-b06 Java HotSpot(TM) Client VM
Comment 31 Steven Michaud [:smichaud] (Retired) 2010-09-29 09:01:55 PDT
> Java Plug-in 1.6.0_21
> Using JRE version 1.6.0_21-b06 Java HotSpot(TM) Client VM

This is puzzling, and I'm not able to reproduce your security
violation (reading any user-accessible file) on a Ubuntu Linux 9.10
installation with Sun Java 1.6.0_20 and FF 3.5.12.

Please double-check that FF really is using Java 6 by visiting the
following site:

http://browserspy.dk/java.php

Then if it is, please also do the following:

1) Run FF 3.5.X and load at least one Java applet (for example the
   ones at http://browserspy.dk/java.php).

2) Use "ps ax | grep firefox" to find Firefox's process id.

3) Run gdb and attach to the Firefox process by entering "gdb Firefox
   [firefox-pid]".

4) In gdb (at the "(gdb)" prompt) enter "info sharedlibrary".

   Look through the list for either "libnpjp2.so" (which is the main
   component of Java Plugin2) or "libjavaplugin_oji.so" (which is the
   main component of the old OJI plugin).

Which do you find?
Comment 32 Steven Michaud [:smichaud] (Retired) 2010-09-29 09:29:42 PDT
(Following up comment #31)

Another question:

If (as I expect) you find that you're using libjavaplugin_oji.so (the
old OJI plugin) in Java 6, please also check that libnpjp2.so exists
somewhere in your Java 6 installation.  One way to do this is to "cd"
to the top level of your Java 6 installation and enter "find . -name
libnpjp2.so".  Also check which of these two plugins is available in
your Firefox distro's "plugins" directory.

It's my understanding that, since at least FF 3.5, Firefox always
prefers Java Plugin2 over the old OJI plugin where both are available.
But (once again) I could be wrong about this.

Another, easier way to tell which Java plugin you're using:

Go to "about:plugins" and see which plugin binary is listed under
"File name" -- libjavaplugin_oji.so or libnpjp2.so.
Comment 33 Steven Michaud [:smichaud] (Retired) 2010-09-29 09:48:49 PDT
And still more information:

I just found out that, on the Linux system where I've been testing
(which is Ubuntu 9.04, not 9.10 as I mentioned earlier), there's a
"/etc/alternatives/javaplugin.so" soft link that tells Firefox which
Java plugin to use (and which points to libnpjp2.so on my system).

As an experiment, I tried putting soft links to both plugins in a FF
3.5.X distro's "plugins" directory.  Both show up in about:plugins,
and gdb shows that both binaries get loaded.  But I'm unable to read
arbitrary user files using that distro -- which indicates I may be
right about FF 3.5.X always preferring Java Plugin2 when both it and
the old OJI plugin are present.
Comment 34 Steven Michaud [:smichaud] (Retired) 2010-09-29 10:00:07 PDT
> "/etc/alternatives/javaplugin.so"

Oops, it's "/etc/alternatives/mozilla-javaplugin.so".
Comment 35 Steven Michaud [:smichaud] (Retired) 2010-09-29 10:12:12 PDT
>> I suggest we fix this by backporting the code that stops FF 3.6 and
>> above from using Sun's old OJI Java plugin (that only uses Java
>> Plugin2).
>
> I'm referring to the patch for bug 497423.

It now looks like we need both to blocklist versions of the Java
plugin older than Java SE 6 Update 14 (as bug 497423 does on platforms
other than the Mac) and to specifically blocklist the
"libjavaplugin_oji.so" binary (on Linux, and perhaps also on other
Unix-like OSes).
Comment 36 Steven Michaud [:smichaud] (Retired) 2010-09-29 10:27:42 PDT
We might want to also blocklist "npoji610.dll" on Windows.
Comment 37 Daniel Veditz [:dveditz] 2010-09-29 10:37:13 PDT
We probably can't simply refuse to use older java on the older branch. We need to see if we can avoid instantiating Java with a principal that it's going to misunderstand. In other words, a scheme whitelist.
Comment 38 Daniel Veditz [:dveditz] 2010-09-29 10:39:10 PDT
I'm changing status back from "fixed", because only part was fixed. We may cover the rest of the bug in a separate bug to avoid confusing things here any more (but if so will link it as a "Depends on" bug).
Comment 39 Steven Michaud [:smichaud] (Retired) 2010-09-29 10:50:11 PDT
Actually this *is* still fixed on the 1.9.2 branch:

The problem only happens with the old OJI plugin, and the 1.9.2 branch
no longer supports OJI except on the Mac -- where this bug has been
fixed by JEP 0.9.7.4.
Comment 40 Steven Michaud [:smichaud] (Retired) 2010-09-29 11:08:14 PDT
(Following up comment #39)

> The problem

I was referring only to the security hole.

But it's true that the crash bug (with Java Plugin2) happens also on
the 1.9.2 branch (FF 3.6.X) and the trunk (FF 4 and above).  And it
might be possible to fix both the crash bug (on FF 3.6 and up) and the
security hole (on FF 3.5.X) by avoiding using "malformed principals"
in scripts that use Java.
Comment 41 Gregory Fleischer 2010-09-29 19:50:42 PDT
(In reply to comment #32)
> (Following up comment #31)

> If (as I expect) you find that you're using libjavaplugin_oji.so (the
> old OJI plugin) in Java 6, please also check that libnpjp2.so exists
> somewhere in your Java 6 installation.  

Yes, in my test reproducing the problem, I was explicitly using libjavaplugin_oji.so plugin that was symlinked into the distro "plugins" sub-directory.  The /etc/alternatives version was deleted.  

When libnpjp2.so is also symlinked into "plugins" directory, then it is used in preference to the older version.  In this case, the crash behavior is observed.
Comment 42 Damon Sicore (:damons) 2010-10-05 13:46:43 PDT
Steven, can you clarify Comment 40?  Is this still a security hole on trunk?
Comment 43 Steven Michaud [:smichaud] (Retired) 2010-10-05 13:57:05 PDT
> Is this still a security hole on trunk?

As best I can tell, it isn't a security hole on either the trunk or
the 1.9.2 branch -- where FF (on other platforms than OS X) can no
longer use the old OJI Java plugin.

For reference, I quote the first part of my comment #25:

> See particularly comment #14 and comment #17.
>
> It's my conclusion, based on what evidence I can find, that the
> crashes in Java Plugin2's client process are unrelated to the
> security problem in OJI and the JEP on OS X.  But I'm not sure I've
> covered all the bases WRT these crashes -- in large part because I
> don't really have the tools to debug crashes in other processes than
> the browser's main process, particularly on Windows and Linux.
Comment 45 Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-10-12 13:46:13 PDT
So comment 4 scares me a lot. "moz-nullprincipal:{xxxx-xxxx-xxxx}" is returned very much by design, if anything the docs here are outdated/poorly written.

Are we still granting such principals system privileges in the JEP? If so that needs to be fixed.

Should a new bug be filed on this? It seems like this bug as it is covers multiple issues, both the principal one and some sort of related crash. Would be great to only have one issue per bug.
Comment 46 Steven Michaud [:smichaud] (Retired) 2010-10-12 13:52:13 PDT
> Are we still granting such principals system privileges in the JEP?

Not as of JEP 0.9.7.4, which has now been landed on all the live branches (see bug 598453).

Note that, as best I can tell, the security problem (the granting of system privileges to "malformed" principals) only exists when using OJI.
Comment 47 Josh Aas 2010-10-12 15:00:28 PDT
I think we need a quick summary of the remaining security problems that need to be resolved here. Correct me if I'm wrong, but this is what I understand from reading the comments here...

Ignoring any crashes that aren't known to be exploitable for now... OJI-based Java plugins can cause users to become vulnerable. Firefox trunk is safe because it has no OJI support on any platform. Firefox 3.6 is now safe because there is no OJI support for Windows and Linux and JEP for Mac OS X has been patched. Firefox 3.5 remains vulnerable because it can load vulnerable OJI-based Java plugins on all platforms.

So we need a fix for Firefox 3.5.x and the current proposals are 1) block vulnerable plugins 2) Avoid instantiating Java with a principal that is going to misunderstand (a scheme whitelist). Either way we should probably update the 3.5.x JEP.

Is this correct?
Comment 48 Steven Michaud [:smichaud] (Retired) 2010-10-12 15:48:09 PDT
> Is this correct?

Mostly.

> Firefox 3.5 remains vulnerable because it can load vulnerable
> OJI-based Java plugins on all platforms.

Firefox 3.5 isn't vulnerable on OS X, because it also bundles the patched JEP.
Comment 49 Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-10-12 17:36:44 PDT
Thanks Josh and Steven for the summary (This is why one-problem-per-bug is critical for security bugs).

As for the two options, I think it's fine to block based on scheme. null-principal documents rarely happen on the web, so making java not work on them should not cause any sites to break.
Comment 50 Johnny Stenback (:jst, jst@mozilla.com) 2010-10-19 13:46:30 PDT
Here's where I think we're at with this bug: The JEP issue is fixed, which I think was the main issue that was dealt with in this bug. The remaining issues are:

1: Whitelist URL schemes that modern Java plugins are able to deal with and only let the Java plugin do live-connect functionality on such URLs.

2: Figure out what to do with actual live-connect code, i.e. Firefox 3.5.

AFAICT bug 594443 covers issue 1, and I think we should file a separate bug on the issue with the old live-connect code in Firefox 3.5.
Comment 51 Steven Michaud [:smichaud] (Retired) 2010-11-05 12:48:33 PDT
Just to remind everyone:

There's nothing more I can do about this bug.  Others will need to step into deal with the remaining issues.
Comment 52 Jesse Ruderman 2010-11-08 17:12:16 PST
Should we just mark this bug as FIXED once there are bugs on file for the remaining issues?
Comment 53 Steven Michaud [:smichaud] (Retired) 2010-11-11 12:20:32 PST
(Following up comment #51)

> There's nothing more I can do about this bug.  Others will need to
> step into deal with the remaining issues.

This is no longer true -- I discovered some interesting things working
on bug 610525.

I've got a 1.9.1-branch patch that fixes this bug (the security hole)
for the OJI plugin (tested on Linux).  I should shortly have a trunk
patch that fixes this bug (the plugin crash) for Java Plugin2.  Both
use the URL scheme whitelist strategy.

I'll open a new bug for each of these patches, and post their numbers
here.
Comment 54 Steven Michaud [:smichaud] (Retired) 2010-11-12 18:01:33 PST
I've opened bug 611897 and bug 611910.

I've going follow Jesse's suggestion and mark this bug FIXED.
Comment 55 christian 2010-11-16 10:47:00 PST
Setting -fixed flags to match status
Comment 56 Al Billings [:abillings] 2010-11-17 16:20:30 PST
(In reply to comment #1)
> Created attachment 467648 [details]
> Test cases
> 
> Test cases for different scenarios:
>  - read a local file
>  - read URL contents
>  - connect a Socket
>  - launch a process

I've tested this on OS X for 1.9.2 and this is fixed in current builds. Reading this bug, it isn't clear to me if 1.9.2 took any changes to handle versions of this on Windows or Linux. Can something please clarify?
Comment 57 Steven Michaud [:smichaud] (Retired) 2010-11-17 17:04:40 PST
> I've tested this on OS X for 1.9.2 and this is fixed in current
> builds.

Also test on the 1.9.1 branch (on OS X) -- it's fixed there, too.

> Reading this bug, it isn't clear to me if 1.9.2 took any changes to
> handle versions of this on Windows or Linux. Can something please
> clarify?

All matters concerning this bug on Windows and Linux have been spun
off into bug 611897 and bug 611910.
Comment 58 Al Billings [:abillings] 2010-11-17 17:08:56 PST
I planned on checking 1.9.1 later. This was in response to my 1.9.2 verification attempts. I'll take a look at the other bugs.
Comment 59 Al Billings [:abillings] 2010-11-17 17:11:35 PST
This doesn't actually seem to reproduce in 1.9.1 (either shipped or current nightly). I don't see the buggy behavior in 1.9.1.15 on OS X.
Comment 60 Steven Michaud [:smichaud] (Retired) 2010-11-17 17:27:21 PST
JEP 0.9.7.4 (which fixes (or rather works around) this bug on OS X)
has been bundled on the branches since 2010-09-24 (see bug 5908453
comment #4 and following).

So to reproduce this bug you need to use builds (nightlies or
otherwise) from before 2010-09-25.  To see this bug in an OS X
release, you must test with FF 3.6.10 or earlier, or FF 3.5.13 or
earlier.
Comment 61 Henry Jen 2011-03-09 11:03:38 PST
Filed a bug within Oracle to make sure Java VM running the applet won't exit on that exception.
Comment 62 Steven Michaud [:smichaud] (Retired) 2011-03-09 11:27:26 PST
(In reply to comment #61)

By "that exception", I assume you mean the RuntimeException mentioned
in bug 611910 comment #0.
Comment 63 Steven Michaud [:smichaud] (Retired) 2011-03-09 11:34:36 PST
(Following up comment #62)

> By "that exception", I assume you mean the RuntimeException
> mentioned in bug 611910 comment #0.

Or rather the MalformedURLException that triggers the
RuntimeException.
Comment 64 Henry Jen 2011-03-09 11:52:45 PST
I should have be more precise. The RuntimeException should not exit the VM, and we should probably not even throw it. The MalformdURLException is expected based on the input from the test case.
Comment 65 Steven Michaud [:smichaud] (Retired) 2011-03-25 10:28:13 PDT
This bug has been fixed for several months now.  Any objection to making it world-readable?

Note You need to log in before you can comment on or make changes to this bug.