NSPR supports opening of UNC Paths, which can leak Windows OS Credentials




Networking: File
11 years ago
2 years ago


(Reporter: lsg-mtso, Unassigned)


({privacy, sec-low})

Windows XP
privacy, sec-low
Bug Flags:
blocking1.9 -
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:low local P5] compat issue if we fix this?)



11 years ago
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
2. Launch a sniffer like wireshark.
3. In the URL bar, type 'file:///\\\foo'
4. Inside of the sniffer, you should see Windows initiate traffic to  

Actual Results:  
Windows will initiate an SMB connection to Windows Lanman and NTLM hashes will be sent out to  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"


11 years ago
Component: OS Integration → Networking: File
Product: Firefox → Core
QA Contact: os.integration → networking.file


11 years ago
Flags: blocking1.9?
Flags: blocking1.8.1.4?
Ever confirmed: true
Flags: blocking1.8.1.4? → wanted1.8.1.x+
Keywords: privacy
Whiteboard: [sg:low]
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.  

Comment 4

11 years ago
Not going to block on this, except as part of the general same-origin tightening in bug 230606
Flags: blocking1.9? → blocking1.9-
Group: core-security
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.
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.