Open Bug 1482368 Opened 3 years ago Updated 3 years ago

same origin policy for file: URI and NTFS symlink and junction point

Categories

(Core :: Security: CAPS, enhancement)

Unspecified
Windows
enhancement
Not set
normal

Tracking

()

UNCONFIRMED

People

(Reporter: atmtaatmta, Unassigned)

References

Details

(Keywords: csectype-disclosure, csectype-sop, Whiteboard: [reporter-external] [client-bounty-form] [verif?])

Attachments

(1 file)

187.89 KB, application/zip
Details
Attached file report.zip
According to https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs

>Starting in Gecko 1.9, files are allowed to read only certain other files.  Specifically, a file can read another file only if the parent directory of the originating file is an ancestor directory of the target file.

But this can be bypassed if use symlink or junction point on NTFS filesystem. Symlink or junction point can be created on NTFS-formatted flash drive, and if you put html file in it, you can go through symlink/junction point and read any file.

check attachment
Flags: sec-bounty?
OS: Unspecified → Windows
I was under the impression that files can read any other files, despite that documentation. Dan, is that right?
Group: firefox-core-security → dom-core-security
Component: Security → Security: CAPS
Flags: needinfo?(dveditz)
Product: Firefox → Core
The documentation is correct.

But the protection is there so that files that are loaded from disk (e.g. from the downloads folder!) don't get to read the whole disk.

If you assume the attacker has arbitrary disk write access to start with, then yes, they can use a symlink, or a hardlink, or heck, just write out a native executable and have you run it.
But what if attacker leave NTFS-formatted USB flash drive with "readme.html" file and symlink on it somewhere, and someone find it and open html file(expecting that it's safe)?
Or maybe symlink or junction point can be stored in .tar file, and some program will create corresponding symlink or junction point when extract it?

Here is changelog for WinRAR
https://www.rarlab.com/rarnew.htm

>    Version 4.00
...
>   9. If TAR, TAR.GZ or TAR.BZ2 archive contains symbolic or hard links
>      and if destination file system is NTFS, WinRAR will create these
>      links when unpacking such archive. WinRAR will create symbolic links
>      as symbolic and hard links as hard in Windows Vista and newer
>      and it will create all links as hard in older Windows.
If the attacker can create hardlinks, you just lose.  A hardlink _is_ the file in question, by definition.

As far as symlinks go, we could try to resolve those in NS_RelaxStrictFileOriginPolicy if we think this is an attack scenario that's actually worth defending against.  But generally if you double-click on something on an untrusted USB stick, you have already lost.  Really, if you insert an untrusted USB stick you have already lost.
I don't think the symlink case is worth addressing. What we really ought to do is tighten our file:// policy to match Chrome's (bug 803143) at which point it won't matter because whether symlinked or not the file won't be readable.
Depends on: 803143
Flags: needinfo?(dveditz)
(also we have older bugs complaining about this symlink behavior and should probably dupe this.)
Group: dom-core-security
What bug is complaining about this behavior in context of stealing files via symlink?
Flags: sec-bounty? → sec-bounty-
You need to log in before you can comment on or make changes to this bug.