634724 - (CVE-2011-0076) JEP allows almost full local-user access to file system via java.io.FileSystem object

Status: RESOLVED FIXED

(Plugins Graveyard :: Java (Java Embedding Plugin), defect)

Description

[Daniel Veditz [:dveditz]]

Attachment: PoC -- enable Java

Apple's Product Security Team contacted us with the following report:

I work for Apple's Product Security team. We have discovered a vulnerability in the JEP or LiveConnect java bridge in Firefox. We initially investigated this as a bug in the Java distribution, but it now seems to be a Mozilla-specific problem. Therefore I'm giving you the proof-of-concept so that you can investigate further.

===== javafs.html =======
<script>
document.write('Free disk space: ' + java.io.FileSystem.getFileSystem().getSpace(new java.io.File('/'), 0));
</script>
===== cut =======

1. Put javafs.html (contents per the above) on a web server.
2. Visit that page in Firefox.
3. Note how the script was permitted to get a reference to the java.io.FileSystem class, even though it is declared package-local.

I reproduced the issue with Firefox 3.6.13.

Comment 1

[Daniel Veditz [:dveditz]]

So far I have been unable to confirm this on either 3.6.15pre (JEP) or 4.0b12pre (Java2 plugin). I'm using OS X 10.5.8, maybe it's a 10.6.x problem?

Comment 2

[Daniel Veditz [:dveditz]]

Testcase works in 3.6.13 on OS X 10.6.6 (JEP)
Does not work using Java-2 plugin with Minefield on OS X 10.6.6

Comment 3

[Steven Michaud [:smichaud] (Retired)]

> 3. Note how the script was permitted to get a reference to the
> java.io.FileSystem class, even though it is declared package-local.

Dan, please ask Apple where the java.io.FileSystem class "is declared
package-local".

When I have time (this weekend?) I'm going to try to find out exactly
how serious this is.  For example, does it give you the same level of
access to the file system as the currently logged in user?  I have my
doubts, but we do need to find out.

Comment 4

[Daniel Veditz [:dveditz]]

Credit: David Remahl of Apple Product Security

Comment 5

[Daniel Veditz [:dveditz]]

One difference between running 3.6.13 on OSX 10.5 vs 106 is the version of Java you get. On 10.5.8 I get Java 1.5.0_26, and do not suffer the bug. On 10.6.6 bsterne gets Java 1.6.0_22 and can reproduce. Both of us using JEP 0.9.7.3 as shipped.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Actually the current version of the JEP (bundled with Mozilla branch distros) is 0.9.7.4.

Whether or not the java.io.FileSystem class "is declared package-local" (whatever that means), it *is* undocumented.  But Sun/Oracle's JDK source distros do contain source for it (and therefore a list of all its methods).  I'm going to use those methods to see exactly how much an unprivileged user can do with a java.io.FileSystem object.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

Attachment: Better testcase

This is bad, and is truly a bug in the JEP.  It appears to give almost
the same access to the local filesystem as the currently logged on
user:  The java.io.FileSystem class can be used to list directories
and to create and delete files -- though though not (as best I can
tell) to read any files.

Here's a better testcase, which "works" on both OS X 10.6.X and
10.5.X.  The only reason the previous testcase failed on 10.5 is that
J2SE 5.0 java.io.FileSystem class lacks a getSpace() method.

As we've already seen, this bug doesn't exist in Apple/Sun/Oracle's
Java Plugin2 implementation.  Additional tests show it doesn't exist
in Java Plugin2 on Windows or Linux, or even in Sun/Oracle's OJI
plugin (at least on Linux -- I'm unable to test this on Windows).

A "package local" class is one that's supposed to be accessible only
from within the package (which in this case is the "java.lang"
package) -- its definition lacks the "public" keyword.  So even in
privileged code, you get a compiler error if you try to use
java.io.FileSystem in a Java applet or application (though there are
ways around this that work only in privileged code).

There's also a mechanism to prevent access from non-privileged code to
restricted packages (for example all those whose names start with
"sun.").  This works fine in the JEP.  And I was frankly unaware that
there was anything in the "non restricted" packages (e.g. "java.lang")
that might cause trouble.

I was wrong :-(

I have some ideas about fixing this.  I'll be spending the next few
days trying them out.  I hope to have a new JEP (0.9.7.5) in the next
week or so.

Comment 8

[Daniel Veditz [:dveditz]]

Can you launch processes? Add processes? Are there other such packages that might allow worse?  Unless some of those answers are "yes" then sg:critical sounds a bit high. Deleting your OS is a rather severe DoS.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

> Can you launch processes? Add processes?

No, not with java.io.FileSystem.

> Are there other such packages that might allow worse?

I don't know.  And it's rather hard to find out -- you have to search
for every class whose definition lacks the "public" keyword, which is
rather hard to automate.

> Deleting your OS is a rather severe DoS.

You can delete any files that the currently logged on user can delete
-- enough to do pretty severe damage, though not to "delete the OS".
And remember that you can also navigate directories (at least those
accessible to the currently logged on user).

Comment 10

[Daniel Veditz [:dveditz]]

Can you create arbitrary files (limited by user's permissions) and fill them with arbitrary data? That's equivalent to downloading and running a trojan if true (add a Firefox component, have it do the rest of the work next time Firefox starts).

Comment 11

[Steven Michaud [:smichaud] (Retired)]

> Can you create arbitrary files (limited by user's permissions) and
> fill them with arbitrary data?

No.

You can use java.io.FileSystem to delete or create files, but you
can't use it to write to or read from files.  (And you'll get a
security exception if you try to use java.io.File to write to or read
from files.)

I forgot to mention earlier that you can also use java.io.FileSystem
to rename files.  But I don't know if this will let you move files
from one location to another.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

I've got a patch for this that, in considerable testing, fixes the
problem without breaking anything else.

But the problem is subtle, and along the way I discovered another
solution that might turn out to be better in the long run, but which
might take me another week to implement.

So I'm going to put my current patch aside for the next week and work
on FF4 bugs ... of which there's no shortage.  I'll see what I think
when I come back.

By the way, even my current fix addresses more than just
java.io.FileSystem:  It stops JavaScript-to-Java LiveConnect from
accessing any package-local class in "system" packages (like
java.lang).

Comment 13

[Steven Michaud [:smichaud] (Retired)]

> I've got a patch for this that, in considerable testing, fixes the
> problem without breaking anything else.
>
> But the problem is subtle, and along the way I discovered another
> solution that might turn out to be better in the long run, but which
> might take me another week to implement.

While testing for bug 629030, I discovered that my patch made
reloading applets sometimes fail.  So I decided to start over again
from scratch.

I've now got a much better (simpler) patch, but I'm still tweaking it
as I run more tests.  I think I'm a day or two away from "releasing" a
new version (0.9.7.5) that fixes this bug (I won't make the source
code public until some time has passed after this bug is fixed on the
branches, to allow time for people to upgrade).

After the recent security-fix releases (FF 3.6.16 and 3.5.18), the
next regularly-scheduled releases are 3.6.17 and 3.5.19.  As I
understand it, the code freeze for blockers for these versions is
tomorrow (Thursday, 2011-03-24).

For some time this bug has been marked blocking1.9.2.17+ and
blocking1.9.1.19+.  It still is -- these numbers haven't been bumped
since the security-fix releases.  For a while I suspected this was a
mistake, and have been trying to make this Thursday's deadline.  I
still think I can make it, but it will be cutting things very close.

So my question (for whoever can answer it) is:  Does this bug block
the next branch releases (expected to be FF 3.6.17 and 3.5.19), or the
following set of branch releases (expected to be FF 3.6.18 and 3.5.20)?

Needless to say, I need the answer very quickly.

Comment 14

[Daniel Veditz [:dveditz]]

The bug has been blocking "the next (non-chemspill) release" since Feb 25 when it was marked ".15+". The field value was renamed along the way so that it now says .17+ to match the fact that the planned April release was renamed to 3.6.17, but the intended release remained the same. The situation would be clearer if we used alphabetical codenames as proposed by clegnitto, the "macaw" release would remain "macaw" even if you had to insert "anteater" and "boa" releases in the meantime.

The code-freeze tomorrow is still intended to apply to this bug. Release schedules can be found at https://wiki.mozilla.org/Releases

Comment 15

[Steven Michaud [:smichaud] (Retired)]

I've just "released" JEP 0.9.7.5.  I'll ask Josh to do a quick review.

With luck I'll be able to land it on the branches later today.

See bug 644682.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

This is fixed by my patch for bug 644682.