803143 - Local files can access other files in the same directory

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P3)

Description

[Boev Vadim Aleksandrovich]

Attachment: data theft.zip

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121010144125

Steps to reproduce:

qframe.htm opened from the desktop


Actual results:

Shows the data from my file  a password.txt which is located on the desktop.


Expected results:

Show a blank page

Comment 1

[Boev Vadim Aleksandrovich]

If the desktop  run the qframe.htm you can steal a file on desktop.This can be done from any directory, provided that the file will be the same as a directory for a file that can be stolen.

Comment 2

[Boev Vadim Aleksandrovich]

Attachment: example

Comment 3

[Boev Vadim Aleksandrovich]

I  have an addiction to unpack archives to the desktop and save passwords in text documents on the desktop. I think that I am not alone in this.

Comment 4

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Chrome fails the same test with:

XMLHttpRequest cannot load file:///Users/stefan/Downloads/data%20theft/passwords.txt. Origin null is not allowed by Access-Control-Allow-Origin.

Comment 5

[Boev Vadim Aleksandrovich]

Nowhere except Mozilla Firefox fails the same test.

Comment 6

[Boev Vadim Aleksandrovich]

I think Mozilla Firefox determines the file directory as domain  (file:///C:/....) and when comparing  domains coincide and  script works. And in Chrome determines the file directory  as IP and security policy  prohibits actions on a different domain. I could be wrong.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Chrome has a very restrictive file:// security policy: every single file is a different origin.  This unfortunately breaks a lot of use cases (e.g. HTML documentation).

We have a security policy where a file can only access things in the same directory or subdirectories.  This works fine as long as you don't dump unrelated things in the same directory...

It's hard to restrict the thing you're concerned about with here without breaking a huge number of legitimate things people depend on.  :(

Probably worth reading the extensive past discussion about this.

Comment 8

[Boris Zbarsky [:bzbarsky]]

So one question is whether we should just special-case the desktop....

Comment 9

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Boris, should an XMLHTTPRequest actually be able to load a file:// URL at all? Do people depend on that?

FYI: Safari allows me to access ../../../../../../etc/passwd from a local html file in ~/Desktop. So we are somewhere in the middle between Wide Open (Safari) and Very Restricted (Chrome). Not bad?

Comment 10

[Boris Zbarsky [:bzbarsky]]

> Boris, should an XMLHTTPRequest actually be able to load a file:// URL at all? Do people
> depend on that?

People definitely depend on that.

But you don't even need to do XHR.  You could just load the file:// in an iframe and then poke at the resulting DOM, as long as you're same-origin.

Comment 11

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Ok my bad. I thought the XMLHTTPRequest was the exception here. But if you can poke at the DOM for frames in same-origin then the XMLHTTPRequest thought was just a red herring i guess.

Comment 12

[Boev Vadim Aleksandrovich]

Which red herring?I used XHR to get the data from the file, I got them, and I can use this data as I please. For example to display on the screen or sent to my server. What have Iframe ? Or do you want to say that from Iframe can also get the data? But even if so, the problem is not solved are deteriorate. Or am I wrong?

Comment 13

[Boris Zbarsky [:bzbarsky]]

> Or do you want to say that from Iframe can also get the data?

Yes.

Comment 14

[Boev Vadim Aleksandrovich]

But somehow not  I was able to get the data. Well, okay, not really understand about the "red herring"?

Comment 15

[Boev Vadim Aleksandrovich]

Even become interesting. How to get it  local file data from iframe? You have example?

Comment 16

[Boev Vadim Aleksandrovich]

I just tried a lot of things and does not work.

Comment 17

[Boev Vadim Aleksandrovich]

Well, yes, in principle.

Example:

<iframe src="passwords.txt" id="11" ></iframe>

<input type="button" onclick="dd()" value="xXx">

<script>

function dd(){

alert(document.getElementById('11').contentWindow.document.body.outerHTML)

}

</script>

Comment 18

[Daniel Veditz [:dveditz]]

This is public, known behavior of our file: implementation (discussed, for example, in Michal Zalewski's book "The Tangled Web") so no need to hide the bug.

Comment 20

[Daniel Veditz [:dveditz]]

Chrome has a very strict "each file: is a unique origin" approach and doesn't appear to be racking up tons of complaints. Maybe we can switch to an even more restrictive implementation now.

Comment 24

[Andrea Marchesini [:baku]]

I don't think we want to follow the chrome's approach of having unique origin per each file. We already have a 'per-directory' origin that allows us to load resources, workers and so on.
I would close this bug as WORKFORME. Feedback?

Comment 25

[Daniel Veditz [:dveditz]]

We get a steady stream of reports (especially bug bounty seekers) pointing out various bad outcomes from our approach, especially since most files will be run from the default Downloads directory with lots of other juicy sensitive information likely to be nearby. So yeah, in fact, I'd prefer to follow Chrome's approach by default. Yes, there used to be lots of things that depended on this behavior years ago, but I don't see too much stuff these days that says "First, go get Firefox because it doesn't work in any other browser."

Comment 28

[Daniel Veditz [:dveditz]]

(In reply to Vladimir Bostanov from comment #27)
> The origin policy for file:// is not really a bug, but the result of a
> deliberate decision that has been challenged before and is about to be
> changed now. Is that correct?

The current file:/// behavior was an intentional choice that at the time was much stricter than the primordial status quo. The world has moved on and webkit/chrome has shown we can get away with strict unique origins now (bug 1500453).

Comment 31

[Luigi Gubello]

Hi!

I wrote the report 1558299 (duplicate) because I wasn't sure that it is a vulnerability or a feature. After reading same origin policy of Firefox I closed the report but I have opened it again because I have found a working proof-of-concept: abusing Firefox SOP an attacker can steal victim's sent documents via WhatsApp. I think that it is a serious problem, but I see that this "bug" is not a bug but it is a feature. So I have a question: can I write about this on my blog? This bug-feature of Firefox doesn't seem to be a secret.

Best regards

Comment 33

[Daniel Veditz [:dveditz]]

This was fixed in bug 1500453 / bug 1558299