369761 - locally opened HTML can send data from local disk to the attacker

Status: VERIFIED DUPLICATE of bug 230606

(Firefox :: Security, defect)

Description

[Pawel Bragoszewski]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

JavaScript working with iframe tag can send private user data (e.g. dir list, text file content) to an attacker. It is required that malicious HTML file is downloaded and opened from local computer.

More details: http://bragoszewski.com/?page_id=36



Reproducible: Always

Steps to Reproduce:
1. download example file from http://bragoszewski.com/jsexploit/evilWin.html (version for Windows)
2. open file from local computer in Windows XP/Vista

Actual Results:  
A few file names from C: are transfered to http://bragoszewski.com/jsexploit/data.txt


Expected Results:  
Data from local filesystem shouldn't be sent over web without user knowledge. If e.g. file list of C: is shown in iframe tag, content of iframe shouldn't be accessible or iframe src attribute shouldn't be modificable.

I suppose it's also possible to establish a longtime connection, with attacker being able to browse local filesystem and view text files. The exploit also works in Opera 9.1 browser, it doesn't work in IE 6/7 (afaik).

Comment 1

[Alex Vincent [:WeirdAl]]

bz asked me to attempt confirming this bug.  I cannot confirm it.

(1) There's actually a bit of a flaw in the way the test is written; it may not care who submitted the data.
(2) http://bragoszewski.com/jsexploit/data.txt is 404
(3) "Error: uncaught exception: Permission denied to get property HTMLDocument.body" appears about three seconds after the local page loads (file:///C:/Downloads/evilWin.htm)
Even after clicking on the H1 element, all I get is the above error.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/2006120418 Firefox/2.0.0.1

Comment 3

[Pawel Bragoszewski]

Well, this is not the same as bug 2306006. I'm showing that using file:// inside iframe and some JS you can establish a long lasting two-side connection, i.e. create a js backdoor.

btw, in my example data is stored in bragoszewski.com/jsexploit/data.html, not data.txt, sorry.

Comment 4

[Alex Vincent [:WeirdAl]]

Okay, I can now confirm this bug, but it takes a few tries to make it work.  It's a bit unreliable.

Comment 5

[Alex Vincent [:WeirdAl]]

I wasn't able to see the text in the main page, but when I opened http://bragoszewski.com/jsexploit/data.html in a secondary tab and reloaded it, I got the following:

Index of file:///C:/ 98DDK 2/26/2006 16:01:56 AUTOEXEC.BAT 1 KB 3/2/2006 16:40:01 Alex 2/12/2005 19:44:01 CONFIG.SYS 2/5/2005 13:38

We need a more robust testcase, preferably with a timestamp on it.

Comment 6

[Alex Vincent [:WeirdAl]]

bug re-classified by timeless at my request.  The bug was originally filed with the classification, which Jesse cleared when he marked it a dupe.

Comment 7

[timeless]

This is stupid.

This is not new and not interesting. It has essentially always been this way.

I'm resquishing this bug as jesse did and removing the flag.

This is only a problem to the extent that you can convince a user to foolishly download a web application to their computer and run it.

If you can convince a user to download a normal application, or a perl application, the same problems apply. And this is clearly described by jesse in the other bug.

The "exploit" is that a user can be convinced to do something stupid. Everything else is working as designed. And changing the design is precisely the focus of bug 230606.

I'm also fixing the summary.

footnote: I always suggest people run with noscript, the world is much safer if you don't use javascript at all.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Alex, my real question was what IE does here.  I know what Gecko does.  ;)

Note that the URI need not be set on the iframe in question; it could be set on any image, stylesheet, etc.  So the real question is whether IE completely prevents file:// documents from linking to any http:// resources.  If not, this is definitely bug 230606 and nothing else.

Comment 9

[Alex Vincent [:WeirdAl]]

sorry, guys; IE 7 doesn't show anything.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Meaning what?

Comment 11

[Jesse Ruderman]

timeless, see my comments on bug 230606 for why this is easier to exploit than you seem to think.

Also, please don't change bug summaries in offensive ways.

Comment 12

[Jesse Ruderman]

Bug 230606 comment 21 describes IE's behavior.