395343 - escaping "samedir" and "subdir" file: access restrictions

Status: NEW

(Core :: Networking: File, defect, P3)

Description

[Daniel Veditz [:dveditz]]

The same-origin restrictions for file: URIs added in bug 230606 have several modes of varying restriction. The FILEURI_SOP_SAMEDIR and FILEURI_SOP_SUBDIR modes can be fooled with combinations of .. traversal and escaped slashes (see bug 230606 comment 56). Not sure yet if the problem is in the fileURL code or the nsLocalFile code, or bad assumptions they make about each other.

bug 380994 is part of this but may not fix the whole problem.

Comment 1

[Daniel Veditz [:dveditz]]

Attachment: zipped testcase, unpack locally

Here's a testcase that can be used to demonstrate some of the problems. Download and unzip locally. Load fileuri/test.html and click the test() button.

Using about:config you can adjust the security.fileuri.origin_policy pref from 0 to 4 to see what slips through in various modes. The original default setting was going to be 0 but that broke automated tests (bindings and xul overlays are checked for same-origin). The current default is "2", allowing access to files in subdirectories, though might switch to "1" (same directory).

Comment 2

[Daniel Veditz [:dveditz]]

Oh, another access problem is that in FILEURI_SOP_SELF mode the raw URIs are compared, so two things that are the same file might not test as equal. One thing that broke one of the automated tests was that fragment identifiers caused URIs not to match, and an XSLT test resulted in file://foo/bar.txt# which didn't match the original version without the trailing #

Comment 3

[georgi - hopefully not receiving bugspam]

some tests show directory traversal doesn't work.

Comment 4

[Daniel Veditz [:dveditz]]

Oh good, then this is a windows-only issue. I definitely get directory traversal using the attached testcase unzipped locally using security.fileuri.origin_policy set to 1 or 2.

Comment 5

[georgi - hopefully not receiving bugspam]

dvedtitz, please double check it is windoze only.

have you tried unicode attacks on windoze?

http://www.honeynet.org/scans/scan14/sub/som13.txt

quote:
The IIS Unicode exploit was obtained by
GET /guest/default.asp/..%C0%AF../..%C0%AF../..%C0%AF../boot.ini

Comment 6

[georgi - hopefully not receiving bugspam]

Bug 395752 circumvents this, though probably it is another problem

Comment 7

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 8

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258