402998 - java in local file can read any files

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[georgi - hopefully not receiving bugspam]

Attachment: reading first line of '/etc/passwd' via java - open it locally

there are restrictions what local files can read.
this can be bypassed easily with java:
<script>
        var fi=new java.net.URL("file:///etc/passwd").openStream();
        var ri2=new java.io.InputStreamReader(fi);
        var ri=new java.io.BufferedReader(ri2);
	alert(ri.readLine());
</script>	

discsussed in Bug 230606 Comment #72

Comment 1

[Reed Loden [:reed]]

The testcase doesn't work for me when I load it directly from bmo.

Error: uncaught exception: java.security.PrivilegedActionException: java.security.PrivilegedActionException: java.lang.reflect.InvocationTargetException

Comment 2

[georgi - hopefully not receiving bugspam]

(In reply to comment #1)
> The testcase doesn't work for me when I load it directly from bmo.
> 

yes, it doesn't work remotely.
you need to open it locally from disk - it bypasses 'file' restrictions.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Java treats all host-less URIs as having the same origin, no?  It's a pretty serious bug... in Java.

Comment 4

[georgi - hopefully not receiving bugspam]

sure java seems buggy, but the exploit vector is mozilla

Comment 5

[georgi - hopefully not receiving bugspam]

dveditz, if you are hiding this bug check the comment in the description

Comment 6

[Kenneth Russell]

For better or worse, this behavior has been part of the implicit LiveConnect specification in the current OJI-based Java Plug-In for at least five years, and probably more. It isn't a new issue and in my opinion is not a serious vulnerability since it requires the HTML to be on the local disk (which I'm assuming is a difficult thing to achieve with just normal web browsing -- but perhaps I'm wrong).

Changing this behavior might be a compatibility issue, but our plug-in for IE handles things differently. It grants read access recursively to only the directory containing the HTML file on the disk.

The new NPRuntime-based Java Plug-In under development changes the Firefox behavior to be more like IE (in fact, both browsers use the same code path in the new plug-in).

Please indicate whether this appears to be a true vulnerability and not just an oddity of the current implementation.

Comment 7

[georgi - hopefully not receiving bugspam]

(In reply to comment #6)
> For better or worse, this behavior has been part of the implicit LiveConnect
> specification in the current OJI-based Java Plug-In for at least five years,

is it only liveconnect?
there seems some protection for applets according to my tests?

Comment 8

[Kenneth Russell]

(In reply to comment #7)
> is it only liveconnect?
> there seems some protection for applets according to my tests?

It should be only LiveConnect. An unsigned applet loaded from the local file system should only be able to read files in directories underneath the source directory from where the applet came. If you find this to not be the case, please post a test.

Comment 9

[georgi - hopefully not receiving bugspam]

(In reply to comment #8)
> An unsigned applet loaded from the local file
> system should only be able to read files in directories underneath the source
> directory from where the applet came.

this is consistent with my tests

Comment 10

[Kenneth Russell]

(In reply to comment #9)
> this is consistent with my tests

In that case this report should probably be closed as "not a bug".

Comment 11

[georgi - hopefully not receiving bugspam]

(In reply to comment #10)
> (In reply to comment #9)
> > this is consistent with my tests
> 
> In that case this report should probably be closed as "not a bug".
> 

in my opinion this is a java bug, but resolve this report as you wish.

Comment 12

[georgi - hopefully not receiving bugspam]

(In reply to comment #8)
> If you find this to not be the case,
> please post a test.
> 

this is `report' 406541:
https://bugzilla.mozilla.org/show_bug.cgi?id=406541

Comment 13

[Kenneth Russell]

I don't have authorization to see bug 406541.

Comment 14

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #13)
> I don't have authorization to see bug 406541.

Kenneth: I've CCed you, you should be able to see it now.

Comment 15

[Kenneth Russell]

Yes, thanks; bug 406541 updated with information.

Comment 16

[georgi - hopefully not receiving bugspam]

whiteboard set to [sg:moderate]

Comment 17

[Daniel Veditz [:dveditz]]

(In reply to comment #6)
> For better or worse, this behavior has been part of the implicit LiveConnect
> specification in the current OJI-based Java Plug-In for at least five years,

and browsers in general

> It isn't a new issue and in my opinion is not a serious
> vulnerability since it requires the HTML to be on the local disk (which I'm
> assuming is a difficult thing to achieve with just normal web browsing

It turns out to be relatively easy to get a file on the local disk in various ways, all it takes is some social engineering. People are recognizing this as a problem and we've tried to address it in Firefox 3 by limiting which other files a local file has access to. IE7 tried to address the problem by preventing local HTML files from running scripts at all.

> Changing this behavior might be a compatibility issue, but our plug-in for IE
> handles things differently. It grants read access recursively to only the
> directory containing the HTML file on the disk.

That would be much better and more or less match what Firefox 3 will do.

> The new NPRuntime-based Java Plug-In under development changes the Firefox
> behavior to be more like IE (in fact, both browsers use the same code path in
> the new plug-in).

Perhaps we can disable older versions of Java once that has been released, to force people onto the safer platform. We're not fixing Firefox 2, this is a somewhat incompatible change we're making in Firefox 3.

> Please indicate whether this appears to be a true vulnerability and not just
> an oddity of the current implementation.

It has come to be seen as dangerous and browser vendors (not just Mozilla) are trying to work out ways to protect against it. The solution you apply to applets sounds like it would work if simply applied to LiveConnect as well.

Comment 18

[Johnny Stenback (:jst)]

This bug as filed seems to be fixed, I don't think there's anything else we will do here. Java changed their behavior per comment 6, and we block list older Java plugins already (and the pre-npruntime version of the Java plugin no longer works at all). Marking this one as fixed.