Last Comment Bug 410156 - (CVE-2008-2810) URL files (IE bookmarks) cause remote code to run as local file when opened directly
(CVE-2008-2810)
: URL files (IE bookmarks) cause remote code to run as local file when opened d...
Status: RESOLVED FIXED
[sg:moderate]
: verified1.8.1.15
Product: Firefox
Classification: Client Software
Component: Security (show other bugs)
: Trunk
: x86 Windows XP
: P2 normal (vote)
: Firefox 3
Assigned To: Robert Strong [:rstrong] (use needinfo to contact me)
:
Mentors:
Depends on:
Blocks: 408540
  Show dependency treegraph
 
Reported: 2007-12-29 03:27 PST by Fedge
Modified: 2009-01-05 12:05 PST (History)
13 users (show)
mbeltzner: blocking‑firefox3+
dveditz: blocking1.8.1.15+
dveditz: wanted1.8.1.x+
asac: blocking1.8.0.next+
robert.strong.bugs: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch rev1 (3.09 KB, patch)
2008-04-11 10:52 PDT, Robert Strong [:rstrong] (use needinfo to contact me)
benjamin: review-
Details | Diff | Review
patch rev2 w/ test (7.15 KB, patch)
2008-04-14 16:13 PDT, Robert Strong [:rstrong] (use needinfo to contact me)
no flags Details | Diff | Review
patch rev 3 w/ test (8.07 KB, patch)
2008-04-14 17:03 PDT, Robert Strong [:rstrong] (use needinfo to contact me)
benjamin: review+
dveditz: approval1.8.1.15+
mbeltzner: approval1.9+
asac: approval1.8.0.next+
Details | Diff | Review
Different approach to test (777 bytes, patch)
2008-04-17 16:46 PDT, Robert Strong [:rstrong] (use needinfo to contact me)
benjamin: review+
Details | Diff | Review
for 1.8.0 (3.22 KB, patch)
2009-01-05 12:02 PST, Alexander Sack
no flags Details | Diff | Review

Description Fedge 2007-12-29 03:27:16 PST
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.
Comment 1 Daniel Veditz [:dveditz] 2007-12-31 10:27:11 PST
How was it 100% remote code? what was in the local file itself then?
Comment 2 Fedge 2008-01-01 03:55:09 PST
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
Comment 3 Daniel Veditz [:dveditz] 2008-01-09 19:59:35 PST
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.
Comment 4 Doug Turner (:dougt) 2008-01-09 23:13:40 PST
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.
Comment 5 Samuel Sidler (old account; do not CC) 2008-01-14 16:34:41 PST
Rob, can you look at this and determine where it's happening?
Comment 6 Mike Beltzner [:beltzner, not reading bugmail] 2008-02-08 10:52:04 PST
This does not block the final release of Firefox 3.
Comment 7 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-10 19:09:36 PDT
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.
Comment 8 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-10 21:15:09 PDT
Looks like nsClipboard.cpp uses nsIFileProtocolHandler ReadURLFile to handle this for DnD. I should have a patch by 4/11.

cc'ing bsmedberg
Comment 9 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-11 10:52:11 PDT
Created attachment 315139 [details] [diff] [review]
patch rev1

This basically uses the same method as used by nsClipboard.cpp
Comment 10 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-11 14:34:55 PDT
Comment on attachment 315139 [details] [diff] [review]
patch rev1

Benjamin, if you prefer I can if defined(XP_WIN) the new code.
Comment 11 Benjamin Smedberg [:bsmedberg] 2008-04-14 10:46:18 PDT
Comment on attachment 315139 [details] [diff] [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.
Comment 12 Christian :Biesinger (don't email me, ping me on IRC) 2008-04-14 14:25:30 PDT
There is. Linux has .desktop files.
Comment 13 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-14 16:13:17 PDT
Created attachment 315661 [details] [diff] [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.
Comment 14 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-14 17:03:49 PDT
Created attachment 315677 [details] [diff] [review]
patch rev 3 w/ test

I went ahead and hacked the makefile so this test is preprocessed.
Comment 15 Fedge 2008-04-14 18:37:35 PDT
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.
Comment 16 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-14 19:00:15 PDT
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 17 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-14 19:08:23 PDT
Comment on attachment 315677 [details] [diff] [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 18 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-16 14:09:21 PDT
Comment on attachment 315677 [details] [diff] [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 19 Mike Beltzner [:beltzner, not reading bugmail] 2008-04-16 23:37:17 PDT
Comment on attachment 315677 [details] [diff] [review]
patch rev 3 w/ test

a1.9=beltzner
Comment 20 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-17 15:22:21 PDT
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 21 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-17 15:27:00 PDT
Comment on attachment 315677 [details] [diff] [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.
Comment 22 Gary Kwong [:gkw] [:nth10sd] 2008-04-17 15:40:53 PDT
This bug seems to have burnt the Thunderbird: 'MacOSX Darwin 8.8.4 bm-xserve07 Depend Universal Nightly' tinderbox...
Comment 23 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-17 15:44:53 PDT
(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
Comment 24 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-17 16:07:09 PDT
I backed it out and will figure out a better way to do these tests
Comment 25 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-17 16:46:15 PDT
Created attachment 316318 [details] [diff] [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.
Comment 26 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-18 13:46:14 PDT
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 27 Daniel Veditz [:dveditz] 2008-04-25 11:12:04 PDT
Comment on attachment 315677 [details] [diff] [review]
patch rev 3 w/ test

approved for 1.8.1.15, a=dveditz for release-drivers
Comment 28 Robert Strong [:rstrong] (use needinfo to contact me) 2008-04-25 14:11:07 PDT
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
Comment 29 Al Billings [:abillings] 2008-06-10 16:16:19 PDT
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 30 Alexander Sack 2009-01-05 12:01:57 PST
Comment on attachment 315677 [details] [diff] [review]
patch rev 3 w/ test

a=asac for 1.8.0
Comment 31 Alexander Sack 2009-01-05 12:02:38 PST
Created attachment 355435 [details] [diff] [review]
for 1.8.0

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