Closed Bug 803143 Opened 7 years ago Closed Last month

Local files can access other files in the same directory

Categories

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

16 Branch
x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr60 --- affected
firefox-esr68 --- affected
firefox67 --- wontfix
firefox67.0.1 --- wontfix
firefox68 --- affected
firefox69 --- affected

People

(Reporter: skyskif, Unassigned)

References

(Blocks 4 open bugs)

Details

(Keywords: sec-want, Whiteboard: [domsecurity-backlog1][webext-sec])

Attachments

(2 files)

Attached file 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
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.
Attached file example
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.
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.
Nowhere except Mozilla Firefox fails the same test.
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.
Component: Untriaged → Security
Product: Firefox → Core
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.
Whiteboard: DUPEME
So one question is whether we should just special-case the desktop....
Summary: data theft (jQuerty) → Local files can access other files in the same directory
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?
> 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.
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.
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?
> Or do you want to say that from Iframe can also get the data?

Yes.
But somehow not  I was able to get the data. Well, okay, not really understand about the "red herring"?
Even become interesting. How to get it  local file data from iframe? You have example?
I just tried a lot of things and does not work.
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>
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.
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Duplicate of this bug: 1377411
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.
Component: Security → DOM: Security
Keywords: sec-want
Whiteboard: DUPEME
Duplicate of this bug: 1389477
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]
Duplicate of this bug: 1412211
Blocks: 1440622
Duplicate of this bug: 1441066
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?
Flags: needinfo?(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."
Flags: needinfo?(dveditz)
See Also: → 1477067
Group: core-security-release
(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).
Group: core-security-release
Duplicate of this bug: 1541386
Blocks: 1544258
Duplicate of this bug: 1558299

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

Blocks: 1560291
Blocks: 1420296
Duplicate of this bug: 1563390

This was fixed in bug 1500453 / bug 1558299

Status: NEW → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Blocks: 332676
Whiteboard: [domsecurity-backlog1] → [domsecurity-backlog1][webext-sec]
You need to log in before you can comment on or make changes to this bug.