Bugzilla@Mozilla – Bug 410156
URL files (IE bookmarks) cause remote code to run as local file when opened directly
Last modified: 2009-01-05 12:05:49 PST
Summon comment box
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122805 Minefield/3.0b3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122805 Minefield/3.0b3pre I added Firefox to my Send To: menu to allow me to open local HTML and URL files in Firefox because these extensions are associated with my editors. I opened a URL file from my IE favorites folder this way (equivalent of dragging it onto the Firefox executable) and lo and behold, the page loaded as a file: protocol page but then went on to download the HTML from the remote server! This should cause a redirect to the URL embedded in the file rather than running it as a local file containing 100% remote code. I'm sure there's > 20 exploits that could be done after this stage has been reached, including spidering the HD through an iframe and sending the data back via dynamic script tag with relative URL added to the page's code. Reproducible: Always Steps to Reproduce: 1. Add Firefox to Send To menu 2. Send it a URL file Actual Results: Remote code loaded under the file: protocol Expected Results: Remote page URL in the address bar, then page load.
How was it 100% remote code? what was in the local file itself then?
URL files only contain a URL, the idea is that a browser loads the file and reads the URL then goes to the page specified by the URL in the file. Internet Explorer shortcuts (favorites) are stored in files with a .url extension. Windows typically hides the .url extension from users even if the option to show file extensions is specified in the folder options, similar to the way .lnk and .pif files are treated so that's why you have never seen this file extension or investigated this type. Here's a description of the format: http://www.cyanwerks.com/file-format-url.html
Sorry for the holiday-induced delay. Confirming bug. I was fooled by the statement "equivalent of dragging it onto the Firefox executable" and was dropping the favorite onto an open browser window. That works fine, the correct site is opened. But right-clicking on the .url shortcut and choosing SendTo, or dragging it onto the Firefox _shortcut_ icon behaves as described: remote content is loaded as a file: uri (so all relative URIs on the page are broken). Ugly if it's content you want, absolutely no protection from evil content in-line or loaded from absolute URIs. On the trunk the file access changes prevent this from being more than a minor security problem, it's just a bug. But FF2 has no such protection and isn't likely to because it's a compatibility change.
we can autoresolve shortcut files in nsLocalFileWin (http://mxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileWin.cpp#846). So, if you pass mozilla a file on the command line and this file is a shortcut and the nsLocalFileWin is autoresolving, my guess is that you will see something as described here -- a file: network load start that ends up loading whatever the file shortcut points to. Maybe we can simply check if he incoming file on the command line is a shortcut, if it is, change it at that point to be he target of the file.
Rob, can you look at this and determine where it's happening?
This does not block the final release of Firefox 3.
I took an initial look at this and I suspect that we are taking the .url file, going back to the OS, and then downloading the page. It appears that nsILocalFile only has a facility for resolving .lnk's and not .url's so we would have to add that capability somewhere. Chances are the reason it works when dropping a .url onto the urlbar is that we ask the OS for a url, the OS reads the url from the .url file, and the OS gives us the url.
Looks like nsClipboard.cpp uses nsIFileProtocolHandler ReadURLFile to handle this for DnD. I should have a patch by 4/11. cc'ing bsmedberg
Created attachment 315139 [details] [review] patch rev1 This basically uses the same method as used by nsClipboard.cpp
Comment on attachment 315139 [details] [review] patch rev1 Benjamin, if you prefer I can if defined(XP_WIN) the new code.
Comment on attachment 315139 [details] [review] patch rev1 This needs a unit test. And yes, I think we should #ifdef XP_WIN this, unless there's a known equivalent on mac/linux that we should be supporting.
There is. Linux has .desktop files.
Created attachment 315661 [details] [review] patch rev2 w/ test Benjamin, I didn't ifdef the new code since it is implemented on Windows, Linux, and OS2. In the future it could be implemented on Mac OS X for .webloc files on Mac OS X. I'm unsure how to best test per platform and just did a best effort at this time. Suggestions? Also, I will put the data files in the subdirectory of unit/data when / if I land this.
Created attachment 315677 [details] [review] patch rev 3 w/ test I went ahead and hacked the makefile so this test is preprocessed.
Not familiar with your code but this filetype is used on all versions of Windows so if the constant WIN_XP only gets defined under XP then it's still gonna be a problem for 9X and 2K. If WIN_XP gets defined under Windows in general, sorry for the spam.
It is just an unfortunate coincidence that there is an Windows XP OS and we use XP_WIN (XP = Cross Platform) in our code... hence why there is an XP_UNIX and XP_MACOSX even though there isn't a Mac OS X XP or UNIX XP.
Comment on attachment 315677 [details] [review] patch rev 3 w/ test >Index: toolkit/components/commandlines/test/unit/test_bug410156.desktop >=================================================================== >RCS file: toolkit/components/commandlines/test/unit/test_bug410156.desktop >diff -N toolkit/components/commandlines/test/unit/test_bug410156.desktop >--- /dev/null 1 Jan 1970 00:00:00 -0000 >+++ toolkit/components/commandlines/test/unit/test_bug410156.desktop 15 Apr 2008 00:03:03 -0000 >@@ -0,0 +1,7 @@ >+[Desktop Entry] >+Version=1.0 >+Encoding=UTF-8 >+Name=test_bug410156 >+Type=Link >+URL=http://www.bug410156.com// I removed the extra trailing / in my tree
Comment on attachment 315677 [details] [review] patch rev 3 w/ test Drivers, this uses essentially the same code as the clipboard code for resolving urls within files (e.g. .url on Windows and .desktop on Linux) so it should be fairly safe. It also includes tests for both of these.
Comment on attachment 315677 [details] [review] patch rev 3 w/ test a1.9=beltzner
Checked in to trunk Checking in mozilla/toolkit/components/commandlines/src/nsCommandLine.cpp; /cvsroot/mozilla/toolkit/components/commandlines/src/nsCommandLine.cpp,v <-- nsCommandLine.cpp new revision: 1.18; previous revision: 1.17 done Checking in mozilla/toolkit/components/commandlines/test/Makefile.in; /cvsroot/mozilla/toolkit/components/commandlines/test/Makefile.in,v <-- Makefile.in new revision: 1.2; previous revision: 1.1 done RCS file: /cvsroot/mozilla/toolkit/components/commandlines/test/unit/test_bug410156.js.in,v done Checking in mozilla/toolkit/components/commandlines/test/unit/test_bug410156.js.in; /cvsroot/mozilla/toolkit/components/commandlines/test/unit/test_bug410156.js.in,v <-- test_bug410156.js.in initial revision: 1.1 done RCS file: /cvsroot/mozilla/toolkit/components/commandlines/test/unit/data/test_bug410156.desktop,v done Checking in mozilla/toolkit/components/commandlines/test/unit/data/test_bug410156.desktop; /cvsroot/mozilla/toolkit/components/commandlines/test/unit/data/test_bug410156.desktop,v <-- test_bug410156.desktop initial revision: 1.1 done RCS file: /cvsroot/mozilla/toolkit/components/commandlines/test/unit/data/test_bug410156.url,v done Checking in mozilla/toolkit/components/commandlines/test/unit/data/test_bug410156.url; /cvsroot/mozilla/toolkit/components/commandlines/test/unit/data/test_bug410156.url,v <-- test_bug410156.url initial revision: 1.1 done
Comment on attachment 315677 [details] [review] patch rev 3 w/ test 1.8.1.15 Drivers, this uses essentially the same code as the clipboard code for resolving urls within files (e.g. .url on Windows and .desktop on Linux) so it should be fairly safe. It also includes tests on trunk for both of these.
This bug seems to have burnt the Thunderbird: 'MacOSX Darwin 8.8.4 bm-xserve07 Depend Universal Nightly' tinderbox...
(In reply to comment #22) > This bug seems to have burnt the Thunderbird: 'MacOSX Darwin 8.8.4 bm-xserve07 > Depend Universal Nightly' tinderbox... Looking
I backed it out and will figure out a better way to do these tests
Created attachment 316318 [details] [review] Different approach to test Benjamin, preprocessing seems to be more trouble than it is worth here so I took a different approach. The test on Linux and Windows are the same... they've just been split out into subdirs.
Checked into Trunk I didn't back out the test data files so only checked in the following Checking in mozilla/toolkit/components/commandlines/src/nsCommandLine.cpp; /cvsroot/mozilla/toolkit/components/commandlines/src/nsCommandLine.cpp,v <-- nsCommandLine.cpp new revision: 1.20; previous revision: 1.19 done Checking in mozilla/toolkit/components/commandlines/test/Makefile.in; /cvsroot/mozilla/toolkit/components/commandlines/test/Makefile.in,v <-- Makefile.in new revision: 1.5; previous revision: 1.4 done RCS file: /cvsroot/mozilla/toolkit/components/commandlines/test/unit/win/test_bug410156.js,v done Checking in mozilla/toolkit/components/commandlines/test/unit/win/test_bug410156.js; /cvsroot/mozilla/toolkit/components/commandlines/test/unit/win/test_bug410156.js,v <-- test_bug410156.js initial revision: 1.1 done RCS file: /cvsroot/mozilla/toolkit/components/commandlines/test/unit/unix/test_bug410156.js,v done Checking in mozilla/toolkit/components/commandlines/test/unit/unix/test_bug410156.js; /cvsroot/mozilla/toolkit/components/commandlines/test/unit/unix/test_bug410156.js,v <-- test_bug410156.js initial revision: 1.1 done
Comment on attachment 315677 [details] [review] patch rev 3 w/ test approved for 1.8.1.15, a=dveditz for release-drivers
Checked into MOZILLA_1_8_BRANCH Checking in mozilla/toolkit/components/commandlines/src/nsCommandLine.cpp; /cvsroot/mozilla/toolkit/components/commandlines/src/nsCommandLine.cpp,v <-- nsCommandLine.cpp new revision: 1.13.2.2; previous revision: 1.13.2.1 done
Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.15pre) Gecko/2008061005 BonEcho/2.0.0.15pre.
Comment on attachment 315677 [details] [review] patch rev 3 w/ test a=asac for 1.8.0
Created attachment 355435 [details] [review] for 1.8.0