User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/418.9.1 (KHTML, like Gecko) Safari/419.3 Build Identifier: Calls to open a file on Windows will allow UNC paths (\\server\dir\file). When this is performed Windows can leak the users OS credentials, or SMB proxying. While exploiting through file:// is difficult for a remote attacker due to FIrefox not honoring file:// urls via http, there are other methods for attack. One example is Michael Zalewski's bookmarklet bug. Modifying his code to window.open a file:// URL will work if someone clicks on a bookmarklet when they are already on a page displaying a file:// url. There are likely to be other attack vectors... Reproducible: Always Steps to Reproduce: The easiest way to show the underlying problem is to: 1. Run a firefox on a machine not on a domain, lets assume this machine is 192.168.2.1 2. Launch a sniffer like wireshark. 3. In the URL bar, type 'file:///\\192.168.2.2\foo' 4. Inside of the sniffer, you should see Windows initiate traffic to 192.168.2.2. Actual Results: Windows will initiate an SMB connection to 192.168.2.2. Windows Lanman and NTLM hashes will be sent out to 192.168.2.2. These hashes are known to be crackable using publicly available tools. Expected Results: NSPR should make sure that UNC paths do not get passed to underlying Windows OS file handling (e.g. CreateFile) functions. There are also some special files that shouldnt be opened, including: "CON ", "PRN ", "NUL ", "AUX ", "LPT1 ", "LPT2 ", "LPT3 ", "LPT4 ", "COM1 ", "COM2 ", "COM3 ", "COM4"
Component: OS Integration → Networking: File
Product: Firefox → Core
QA Contact: os.integration → networking.file
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking184.108.40.206? → wanted1.8.1.x+
Wan-Teh or Nelson, can either of you take look at this?
should NSPR really disallow this?
It is perfectly correct for NSPR to do this. It may be that a product such as a BROWSER may wish to disallow access to such path names in some contexts (e.g. from a file:// URI), but if so that is a browser issue, not an NSPR issue. NSPR exists to support many products, of which the browser is only one. Browser policy issues must be kept out of NSPR.
Not going to block on this, except as part of the general same-origin tightening in bug 230606
Flags: blocking1.9? → blocking1.9-
Whiteboard: [sg:low] → [sg:low local P5] compat issue if we fix this?
I think context of the containing reference is the only sensible approach here. i.e. looking for cases where file:// is generally accessed inappropriately.. in general, we need encrypted protocols to prevent this kind of leakage - cookies, http auth, etc have ismilar issues otherwise.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.