java in local file can read any files

RESOLVED FIXED

Status

()

RESOLVED FIXED
11 years ago
3 years ago

People

(Reporter: guninski, Assigned: dveditz)

Tracking

Trunk
x86
Linux
Points:
---
Bug Flags:
wanted1.8.1.x -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate] bypass file: origin fix)

Attachments

(1 attachment)

Created attachment 287808 [details]
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
(Reporter)

Updated

11 years ago
Blocks: 230606
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
(Reporter)

Updated

11 years ago
Attachment #287808 - Attachment description: reading first line of '/etc/passwd' via java → reading first line of '/etc/passwd' via java - open it locally
(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.
Assignee: nobody → dveditz
Component: Security → Security
Product: Firefox → Core
QA Contact: firefox → toolkit
Java treats all host-less URIs as having the same origin, no?  It's a pretty serious bug... in Java.
sure java seems buggy, but the exploit vector is mozilla
(Assignee)

Updated

11 years ago
Group: security
dveditz, if you are hiding this bug check the comment in the description

Comment 6

11 years ago
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.
(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

11 years ago
(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.
(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

11 years ago
(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 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.
(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

11 years ago
I don't have authorization to see bug 406541.
(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

11 years ago
Yes, thanks; bug 406541 updated with information.
whiteboard set to [sg:moderate]
Whiteboard: [sg:moderate]
(Assignee)

Comment 17

11 years ago
(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.
Flags: wanted1.8.1.x-
Whiteboard: [sg:moderate] → [sg:moderate] bypass file: origin fix
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Updated

3 years ago
Group: core-security → core-security-release
(Assignee)

Updated

3 years ago
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.