Closed
Bug 402998
Opened 17 years ago
Closed 13 years ago
java in local file can read any files
Categories
(Core :: Security, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: guninski, Assigned: dveditz)
References
Details
(Whiteboard: [sg:moderate] bypass file: origin fix)
Attachments
(1 file)
(deleted),
text/html
|
Details |
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•17 years ago
|
||
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•17 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
Reporter | ||
Comment 2•17 years ago
|
||
(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.
Updated•17 years ago
|
Assignee: nobody → dveditz
Product: Firefox → Core
QA Contact: firefox → toolkit
Comment 3•17 years ago
|
||
Java treats all host-less URIs as having the same origin, no? It's a pretty serious bug... in Java.
Reporter | ||
Comment 4•17 years ago
|
||
sure java seems buggy, but the exploit vector is mozilla
Assignee | ||
Updated•17 years ago
|
Group: security
Reporter | ||
Comment 5•17 years ago
|
||
dveditz, if you are hiding this bug check the comment in the description
Comment 6•17 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.
Reporter | ||
Comment 7•17 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,
is it only liveconnect?
there seems some protection for applets according to my tests?
Comment 8•17 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.
Reporter | ||
Comment 9•17 years ago
|
||
(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•17 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".
Reporter | ||
Comment 11•17 years ago
|
||
(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.
Reporter | ||
Comment 12•17 years ago
|
||
(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•17 years ago
|
||
I don't have authorization to see bug 406541.
Comment 14•17 years ago
|
||
(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•17 years ago
|
||
Yes, thanks; bug 406541 updated with information.
Assignee | ||
Comment 17•17 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
Comment 18•13 years ago
|
||
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
Closed: 13 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Group: core-security → core-security-release
Assignee | ||
Updated•9 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•