Last Comment Bug 370555 - (CVE-2007-1004) URL bar not always updated when scripts interact with about:blank windows
(CVE-2007-1004)
: URL bar not always updated when scripts interact with about:blank windows
Status: RESOLVED FIXED
[sg:low spoof] need branch approval
: fixed-seamonkey1.0.9, fixed-seamonkey1.1.2, verified1.8.0.12, verified1.8.1.4
Product: Firefox
Classification: Client Software
Component: Security (show other bugs)
: unspecified
: All All
: -- normal with 3 votes (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
:
:
Mentors:
http://lcamtuf.coredump.cx/fftests_wi...
: 390627 402060 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-15 15:07 PST by Michal Zalewski
Modified: 2008-09-22 01:32 PDT (History)
28 users (show)
dveditz: blocking1.8.1.4+
dveditz: blocking1.8.0.12+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Don't suppress about:blank if there's an opener (1.8 branch) (3.18 KB, patch)
2007-02-17 03:12 PST, Daniel Veditz [:dveditz]
mconnor: review+
Details | Diff | Splinter Review
1.8 branch patch (2.72 KB, patch)
2007-04-28 14:30 PDT, Daniel Veditz [:dveditz]
dveditz: approval1.8.1.4+
dveditz: approval1.8.0.12+
Details | Diff | Splinter Review
Suite trunk port (2.70 KB, patch)
2007-04-29 13:37 PDT, neil@parkwaycc.co.uk
csthomas: review+
Details | Diff | Splinter Review
Branch version of attachment 263206 (3.03 KB, patch)
2007-04-29 13:43 PDT, neil@parkwaycc.co.uk
csthomas: review+
Details | Diff | Splinter Review
1.8.0.x version of attachment 263206 (3.35 KB, patch)
2007-04-29 13:48 PDT, neil@parkwaycc.co.uk
csthomas: review+
Details | Diff | Splinter Review

Description Michal Zalewski 2007-02-15 15:07:23 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: 

This is a minor issue, but the behavior exhibited by FF is counterintuitive and may help phishers, so I thought it's worth addressing.

It is possible for a script placed on a webpage to open "about:blank" window. This will open a new window with an empty URL bar. The script can then modify the displayed document, and certain methods for doing this will automatically set the URL bar to the address of the page that created the window (for example, wnd.document.write() will do just that). This is fairly intuitive and informs the user about the origin of the displayed code.

Should we choose to modify the default layout of "about:blank" through the use of createElement / createTextNode / appendChild on wnd.document.body, the URL bar remains blank, however. 

As a result, it is possible for the attacker to replace the current window with a fully-functional HTML document displayed in a window with blank URL bar, that is otherwise impossible to identify (no useful data in 'properties' dialog, disabled 'reload' button).

When used for phishing, this would quite certainly improve the odds against a casual user, and can be used to spoof various browser messages and prompts without exposing a suspiciously-looking site address (or data: URL scheme).

I haven't tested it, but I guess it also makes the life of a phishing detection functionality a bit harder.

Test case: http://lcamtuf.coredump.cx/fftests_win.html


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Comment 1 Michal Zalewski 2007-02-16 14:55:13 PST
A quick update:

1) The attack works when new windows are opened to tabs, not windows. This seems to be the default behavior for FF 2.0.0.1.

2) The attack might be more serious than I previously indicated: about:blank windows can be used to bypass a measure implemented to minimize the risk of UI spoofing attacks (by default, locationbar-less windows that may contain fake URL bars or "browser" prompts and messages, have site address forcibly prepended to window title; windows filled in the aforementioned manner are not subject to this). I added a testcase at the aforementioned URL to demonstrate the problem.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2007-02-16 15:58:54 PST
So on trunk we _could_ just show the opener's URI (from the principal) for about:blank windows, no?

Branch is a little harder...
Comment 3 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-02-16 17:07:12 PST
Showing the opener URI makes me nervous since that's a lie too. But maybe it's the best option...
Comment 4 Jordan M. 2007-02-16 18:12:50 PST
(In reply to comment #3)
> Showing the opener URI makes me nervous since that's a lie too. But maybe it's
> the best option...
>
If that's the best option, should we do anything at all? Shouldn't we treat it like any other page? Surely if there's a better way to make sure any other site's URL is correct, we can apply the concept to this page? Or maybe I missed something?
Comment 5 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-02-16 18:15:37 PST
There is no correct URL for the page since it's not been loaded from anywhere. It has been created by javascript.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2007-02-16 18:56:40 PST
Sicking, in what way is the opener URI (or rather the URI from the principal of the about:blank page) a lie?  Or rather, how is it more of a lie than what we show for wyciwyg URIs?
Comment 7 Jordan M. 2007-02-16 19:08:14 PST
Doesn't the content have to be read from somewhere, e.g. in his example, zombo.com. Could we use that in any way?
Comment 8 Jordan M. 2007-02-16 19:53:55 PST
Is #2 from included in this discussion? If not, has anyone submitted a bug about it?
Comment 9 Jordan M. 2007-02-16 19:55:03 PST
*edit: From http://lcamtuf.coredump.cx/fftests.html
Comment 10 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-02-17 01:41:09 PST
The content doesn't have to be read from anywhere, no. It can be completely generated by javascript.

bz: yeah, it's no more of a lie than wyciwyg urls, so i think we should do that.
Comment 11 Daniel Veditz [:dveditz] 2007-02-17 03:12:58 PST
Created attachment 255442 [details] [diff] [review]
Don't suppress about:blank if there's an opener (1.8 branch)

On the branch showing about:blank is better than nothing. With or without a host in the titlebar showing a faked location bar is going to fool people, but then this gets back to bug 22183.

Note also the recent study of EV Cert ("green url bar") effectiveness that found a lot of people spoofed simply by putting an image of a complete browser window with the EV indicators inside the actual window content.
Comment 12 Michal Zalewski 2007-02-17 15:56:26 PST
Showing hostname in window title was a very weak UI spoofing protection in the first place; Opera deals with this more nicely, by displaying a minimalistic, non-editable URL on the top of locationbar-less windows. 

What's more important, MSIE7 and Opera both enable the user to disable the ability for windows to hide location bars, something that isn't a visible config option in FF preferences (why? it's possible to disable Javascript status bar hiding, for example).

(...now slightly off-topic...)

While we're at it, I'd seriously consider a 2004 decision not to address the possibility of spoofing these yellow security notification bars that appear at the top of a page. These are 100% spoofable, and users who haven't memorized all legitimate ones pretty much have no way of telling ("This page requires a plugin, click here to install" / "An important security update to Firefox is available" -> owned machine). This problem was reported ages ago, but marked as WONTFIX, with a comment that the user is ultimately responsible for his actions (which is of course silly - a non-expert user has no way of telling whether the message is coming from the browser or not).

A very simple change that makes the yellow bar partly, visibly overlap with the URL bar or other UI elements outside the document window would make such attacks much less effective.

This is an issue that goes beyond that single Bugzilla entry, but I wanted to drop that thought for your consideration.
Comment 13 Ben Bucksch (:BenB) 2007-02-17 16:09:30 PST
Michal, I agree about the yellow bar, it's incredibly dangerous. And we're educating users the wrong way. As you said, offtopic here, the best place would be in newsgroup mozilla.dev.apps.firefox (on nttp://news.mozilla.org).
Comment 14 Jordan M. 2007-02-17 17:40:42 PST
(In reply to comment #12)
> Showing hostname in window title was a very weak UI spoofing protection in the
> first place; Opera deals with this more nicely, by displaying a minimalistic,
> non-editable URL on the top of locationbar-less windows. 
> 
> What's more important, MSIE7 and Opera both enable the user to disable the
> ability for windows to hide location bars, something that isn't a visible
> config option in FF preferences (why? it's possible to disable Javascript
> status bar hiding, for example).
> 
> (...now slightly off-topic...)
> 
> While we're at it, I'd seriously consider a 2004 decision not to address the
> possibility of spoofing these yellow security notification bars that appear at
> the top of a page. These are 100% spoofable, and users who haven't memorized
> all legitimate ones pretty much have no way of telling ("This page requires a
> plugin, click here to install" / "An important security update to Firefox is
> available" -> owned machine). This problem was reported ages ago, but marked as
> WONTFIX, with a comment that the user is ultimately responsible for his actions
> (which is of course silly - a non-expert user has no way of telling whether the
> message is coming from the browser or not).
> 
> A very simple change that makes the yellow bar partly, visibly overlap with the
> URL bar or other UI elements outside the document window would make such
> attacks much less effective.
> 
> This is an issue that goes beyond that single Bugzilla entry, but I wanted to
> drop that thought for your consideration.
> 
Have to agree with everything said. I've actually thought of mentioning the first two things before this, but don't have the balls to say anything that might be seen as a off-topic. But perhaps would get more attention in separate bug reports?
Comment 15 Jordan M. 2007-02-17 18:41:03 PST
dom.disable_window_open_feature.location = True

=

The option we were looking for?

Or am I the only one who had that automatically set as false?
Comment 16 Michal Zalewski 2007-02-18 02:13:57 PST
(In reply to comment #15)
> dom.disable_window_open_feature.location = True
> The option we were looking for?

Yes, but it's not configurable through the UI (whereas other Javascript restrictions, such as the infinitely less useful statusbar hiding, are a part of the configuration dialogs). Following the suit of other browsers, it probably wouldn't hurt to make it visible and maybe default to 'false'.
Comment 17 Michal Zalewski 2007-02-18 02:14:40 PST
(In reply to comment #16)
> probably wouldn't hurt to make it visible and maybe default to 'false'.

err, 'true'.


Comment 18 Ben Bucksch (:BenB) 2007-02-18 03:21:29 PST
The 2. and 3. button on http://lcamtuf.coredump.cx/ffblank/ is bad enough, even though the hostname is shown in title bar, I bet most users would miss it in favor of the spoofed URLbar.

So, can we please just set dom.disable_window_open_feature.location to true by default (and optionally add UI for it)? That would fix this bug as well, even on branch.
Comment 19 Ben Bucksch (:BenB) 2007-02-18 03:24:47 PST
> That would fix this bug as well, even on branch.

eh, no, it would not, I was confused, button 1 and 3 still works. It would fix button 2.
Comment 20 Michael Ventnor 2007-02-18 03:38:36 PST
(In reply to comment #17)
> (In reply to comment #16)
> > probably wouldn't hurt to make it visible and maybe default to 'false'.
> 
> err, 'true'.
> 

That's bug 337344. There were issues mentioned in that bug that prevent it from being fixed the easy way, for example popup vs normal window heuristics, but from a recent perusal in LXR they seem to not be an issue anymore. I could be wrong. I'm trying to do all I can to speed up a resolution (eg fixing the blocker bugs I'm capable of fixing) since I want that bug marked FIXED as much as you do.

PS. Thank you for all the testcases and security work you do for us. :)
Comment 21 Jordan M. 2007-02-18 07:52:20 PST
(In reply to comment #19)
> > That would fix this bug as well, even on branch.
> 
> eh, no, it would not, I was confused, button 1 and 3 still works. It would fix
> button 2.
> 
If partially fixes 3, as well. Surely most users would notice that there's a space above the menu bar. But 1 is definitely not solved (will probably be solved in 2.0.0.2).
Comment 22 Jesse Ruderman 2007-02-20 00:14:21 PST
Bug 252257 covers yellow-info-bar spoofability.  If there's also a WONTFIXed bug on the same issue, please CC me on it and I'll mark it as a dup of bug 252257 or something.
Comment 23 Martynas Venckus 2007-02-27 14:18:46 PST
This causes the regression when homepage is left unfilled (or about:blank). Everytime i start the browser it goes to the "firstrun" page.
Comment 24 Daniel Veditz [:dveditz] 2007-02-27 15:04:57 PST
I can't reproduce that: with this patch I get a truly blank page on startup if I set the startup option to "use a blank page" or if I set it to "use my homepage" and then make the homepage about:blank.
Comment 25 Ben Bucksch (:BenB) 2007-02-28 03:11:46 PST
Martynas, what you describe could happen when the pref cannot be writte, for whatever reasons. Possible reasons: pref locked, prefs file is readonly etc..
Comment 26 Jordan M. 2007-03-15 21:22:20 PDT
Is Dan's method the general consensus as being the best way to fix this?
Comment 27 Mike Connor [:mconnor] 2007-04-27 13:17:31 PDT
Comment on attachment 255442 [details] [diff] [review]
Don't suppress about:blank if there's an opener (1.8 branch)

>@@ -3848,13 +3848,14 @@ nsBrowserStatusHandler.prototype =
>     var browser = getBrowser().selectedBrowser;
>     var findField = document.getElementById("find-field");
>     if (aWebProgress.DOMWindow == content) {
> 
>       var location = aLocation.spec;
> 
>-      if (location == "about:blank" || location == "") {   //second condition is for new tabs, otherwise
>+      if ((location == "about:blank" && !content.opener) 
>+          || location == "") {   //second condition is for new tabs, otherwise

|| on previous line, make the comment line up properly with the line below please

>         location = "";                                     //reload function is enabled until tab is refreshed

r=me with that addressed
Comment 28 Daniel Veditz [:dveditz] 2007-04-28 14:29:46 PDT
Checked in on trunk with requested changes
Comment 29 Daniel Veditz [:dveditz] 2007-04-28 14:30:40 PDT
Created attachment 263158 [details] [diff] [review]
1.8 branch patch
Comment 30 Boris Zbarsky [:bz] (still a bit busy) 2007-04-29 12:45:53 PDT
Neil, Ctho, you might want an equivalent in Seamonkey.
Comment 31 neil@parkwaycc.co.uk 2007-04-29 13:37:36 PDT
Created attachment 263206 [details] [diff] [review]
Suite trunk port
Comment 32 neil@parkwaycc.co.uk 2007-04-29 13:43:39 PDT
Created attachment 263208 [details] [diff] [review]
Branch version of attachment 263206 [details] [diff] [review]
Comment 33 neil@parkwaycc.co.uk 2007-04-29 13:48:22 PDT
Created attachment 263209 [details] [diff] [review]
1.8.0.x version of attachment 263206 [details] [diff] [review]
Comment 34 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2007-04-29 13:49:24 PDT
Comment on attachment 263208 [details] [diff] [review]
Branch version of attachment 263206 [details] [diff] [review]

Please include more lines of context.
Comment 35 Ian Neal 2007-04-29 14:03:59 PDT
Comment on attachment 263208 [details] [diff] [review]
Branch version of attachment 263206 [details] [diff] [review]

a=me for 1.1.2
Comment 36 Ian Neal 2007-04-29 14:05:21 PDT
Comment on attachment 263209 [details] [diff] [review]
1.8.0.x version of attachment 263206 [details] [diff] [review]

first a=me for SM1.0.9
Comment 37 neil@parkwaycc.co.uk 2007-04-29 14:38:53 PDT
Suite fixes checked in.
Comment 38 Daniel Veditz [:dveditz] 2007-04-30 10:16:34 PDT
Comment on attachment 263158 [details] [diff] [review]
1.8 branch patch

approved for 1.8.1.4, a=release-drivers
Comment 39 Daniel Veditz [:dveditz] 2007-04-30 12:05:04 PDT
checked into 1.8 and 1.8.0 branches
Comment 40 Carsten Book [:Tomcat] 2007-05-16 01:12:23 PDT
verified fixed 1.8.1.4 and 1.8.0.12 using the testcases from Michal Zalewski with builds Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4) Gecko/2007051502 Firefox/2.0.0.4 (Firefox 2.0.0.4 RC3) and Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12 (Firefox 1.5.0.12 RC2). 

Verified after some test runs with new and old builds with this testcases and the URL is no updated on Testcase 3 and the Reload Button is now working on testcase 1 with both branches. Adding verified keyword

Comment 41 Daniel Veditz [:dveditz] 2007-09-24 11:50:13 PDT
*** Bug 390627 has been marked as a duplicate of this bug. ***
Comment 42 Jo Hermans 2007-11-01 10:38:57 PDT
*** Bug 402060 has been marked as a duplicate of this bug. ***
Comment 43 Daniel Veditz [:dveditz] 2008-05-27 13:45:48 PDT
This appears to be the issue described by CVE-2007-1004

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