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

NEW
Assigned to

Status

()

defect
P3
normal
12 years ago
2 years ago

People

(Reporter: dveditz, Assigned: dveditz)

Tracking

Trunk
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.0.x +
wanted1.8.1.x +
wanted1.8.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog])

Attachments

(1 attachment)

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.
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).
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 #
Flags: wanted1.8.1.x+
Flags: blocking1.9?
some tests show directory traversal doesn't work.
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.
OS: All → Windows XP
Hardware: All → PC
Flags: blocking1.8.1.7?
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
Bug 395752 circumvents this, though probably it is another problem
Flags: blocking1.8.1.7? → wanted1.8.0.x+
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Flags: tracking1.9+ → wanted1.9.0.x+
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P3 → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.