RSnake mentioned a potential way to read security sensitive configuration settings from Firefox on ha.ckers.org, with an example PoC from Sergey Vzloman that used the resource:// URL protocol handler in Firefox. Unfortunately, the settings that were read were the default settings inside the Firefox install directory.
An example resource URL would be resource://gre/greprefs/security-prefs.js which reads the security-prefs.js file from your Firefox install directory, which on Windows could be C:\Program Files\Mozilla Firefox\greprefs\security-prefs.js. Mozilla must have acknowledged the potential for directory traversal here, as they have blocked any attempts at including the string ..\ or ../ inside resource: requests.
BK demonstrated in the thread that Mozilla does not properly sanitize the input properly, and that you can circumvent this restriction by using ..%5C instead of ..\ which means that you can read arbitrary files from the local system by exposing the file contents as readable properties on SCRIPT or CSS tags.
For the sake of a demonstration, let’s assume that you have a file called C:\resource.txt that contains
secretinfo = “steal me”
In this case you could expose the local file content to your website with the following script include.
<script src=”resource://gre/..%5C..%5Cresource.txt”></script>
This would expose the secretinfo as a Javascript variable. If you are uncertain of the Firefox installation directory you can always append additional directory traversal separators, but see below for more on that.
Daniel Veditz opened up the ongoing Bugzilla report #367428, given that this is now being discussed in public, and from that report we can see that Mozilla has been struggling to fix this vulnerability since January 18 2007. We can also see that the currently proposed patches are only sanitizing input for the Windows platform and that Linux and Mac directory traversals have not been addressed.
It is good to see that Mozilla has picked up the pace now that this is public knowledge. However, even after they fix the directory traversal vulnerability we can still use the resource protocol to query and read any file inside the Firefox installation directory. This includes reading the update.xml, install.log or even browserconfig.properties which contains your homepage settings. It also allows us to query for the status of any installed plugin.
I don’t want to help out scrupulous advertisers with a ready-to-use script that hands them my homepage setting, so instead I have put up a simple PoC that demonstrates how to read your local Firefox install directory and the status of a few plugins. You can find that at http://larholm.com/misc/ffresourcefile.html ![]()
Regardless of how we look at this you can expect to see a Firefox 2.0.0.4 release very soon. My hope is, regardless of what patch makes into the source tree, that access to the entire resource:// URL protocol handler is blocked for Internet sites.
UPDATE June 11 2007.
Remember to read the follow-up post with details about the patch in firefox 2.0.0.4, http://larholm.com/2007/06/04/unpatched-input-validation-flaw-in-firefox-2004/.
I would also like to point out that Aviv Raff was the first to discover the “.sheet.href” vulnerability component in his post on ha.ckers.org, which is crucial for parsing text from the requested resource ![]()

The Bugzilla report #367428 currently has a resolution of RESOLVED FIXED, despite the fact that the patch does not fix the directory traversal on OS X or Linux.
fix is useless because Firefox 2.0.0.4 is not released and so all users are still unpatched!
Attacker can read information about installed “Windows Updates” by openning rollback files:
[Windows Directory]\$NtUninstallKB[Update ID]$\spuninst\spuninst.txt
Like this:
C:\WINDOWS\$NtUninstallKB892313$\spuninst\spuninst.txt
If file not exists, update most probably is not installed…
more info (rus):
http://www.xakep.ru/post/38360/default.asp
sources:
http://www.xakep.ru/post/38360/source.rar
(continued)
This can be exploited with:
resource://..%5C(…)/WINDOWS/$NtUninstallKB892313$/spuninst/spuninst.txt
Larry Seltzer writes about this vulnerability in PC Magazine.
http://www.pcmag.com/article2/0,1895,2136519,00.asp
Firefox 2.0.0.4 and 1.5.0.12 will be released today, fixing this vulnerability.
http://developer.mozilla.org/devnews/index.php/2007/05/29/firefox-15012-firefox-2004-to-be-available-soon/
Firefox 2.0.0.4 is still vulnerable, I’ve tested it with this PoC:
http://larholm.com/misc/ffresourcefile.html
The PoC at http://larholm.com/misc/ffresourcefile.html is a relatively harmless demonstration of why exposing the resource protocol to web content is a bad idea.
The patch only closes the directory traversal aspect. You can still read local files in Firefox 2.0.0.4, but it is now limited to the files within your Firefox installation directory such as update.xml and install.log that reveal your current patch status.
The patch that was introduced in Firefox 2.0.0.4 accidentally opens up the resource protocol to a separate input validation flaw. I have been kind enough to give Mozilla advance notice of this vulnerability and will follow up here with a separate post on the subject.
resource:///etc/passwd (3 slashes on unix works fine)
Yup, the patch only filters out backslashes (\) and not forward slashes (/) so Linux/Unix/OS X are still vulnerable to the full directory traversal.
I mentioned this as well in the bugzilla case that Mozilla has had open since January.
@Sergey Vzloman
The same thing (i.e. accessing a local file whose path you know) can be done using a backgound ajax file upload, can’t it?
You could upload it to your server and processing it there. Then you could also pass it back to javascript via ajax if desired.
This ajax background fileupload thing seems to be a big security issue to me, is there a way to protect yourself from that?
Is it possible to steal cookies using an ajax backgound file-upload??
I sketched a possible attack here
I am sure this must have been discussed already, but IMHO this is still a big issue. Would be glad to hear your comments if the sketched attack is indeed so easily possible
-ukio
[...] were a number of interesting comments on my previous post, Firefox 0day local file reading. Checking the current Windows patch status was suggested by Sergey Vzloman and H D Moore [...]
Firefox 2.0.0.5 is still vulnerable