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

Status: RESOLVED FIXED

(Core :: Security: CAPS, enhancement)

Description

[atmtaatmta]

Attachment: 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

Comment 1

[Andrew McCreight [:mccr8]]

I was under the impression that files can read any other files, despite that documentation. Dan, is that right?

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[atmtaatmta]

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)?

Comment 4

[atmtaatmta]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Daniel Veditz [:dveditz]]

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.

Comment 7

[Daniel Veditz [:dveditz]]

(also we have older bugs complaining about this symlink behavior and should probably dupe this.)

Comment 8

[atmtaatmta]

What bug is complaining about this behavior in context of stealing files via symlink?

Comment 9

[Andrew McCreight [:mccr8]]

Dan, can this be closed now that bug 803143 has been fixed?

Comment 10

[Daniel Veditz [:dveditz]]

yes, thanks