Closed Bug 370555 (CVE-2007-1004) Opened 17 years ago Closed 17 years ago

URL bar not always updated when scripts interact with about:blank windows

Categories

(Firefox :: Security, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: lcamtuf, Assigned: dveditz)

References

()

Details

(4 keywords, Whiteboard: [sg:low spoof] need branch approval)

Attachments

(5 files)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Whiteboard: [sg:low spoof]
So on trunk we _could_ just show the opener's URI (from the principal) for about:blank windows, no?

Branch is a little harder...
Flags: blocking1.8.1.3?
Flags: blocking1.8.0.11?
Showing the opener URI makes me nervous since that's a lie too. But maybe it's the best option...
(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?
There is no correct URL for the page since it's not been loaded from anywhere. It has been created by javascript.
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?
Doesn't the content have to be read from somewhere, e.g. in his example, zombo.com. Could we use that in any way?
Is #2 from included in this discussion? If not, has anyone submitted a bug about it?
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.
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.
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.
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).
(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?
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?
(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'.
(In reply to comment #16)
> probably wouldn't hurt to make it visible and maybe default to 'false'.

err, 'true'.


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.
> 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.
(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. :)
(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).
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.
This causes the regression when homepage is left unfilled (or about:blank). Everytime i start the browser it goes to the "firstrun" page.
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.
Martynas, what you describe could happen when the pref cannot be writte, for whatever reasons. Possible reasons: pref locked, prefs file is readonly etc..
Is Dan's method the general consensus as being the best way to fix this?
Assignee: nobody → dveditz
Flags: blocking1.8.1.4?
Flags: blocking1.8.1.4+
Flags: blocking1.8.0.12?
Flags: blocking1.8.0.12+
Attachment #255442 - Flags: review?(mconnor)
Whiteboard: [sg:low spoof] → [sg:low spoof] need r=mconnor (still)
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
Attachment #255442 - Flags: review?(mconnor) → review+
Checked in on trunk with requested changes
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [sg:low spoof] need r=mconnor (still) → [sg:low spoof] need branch approval
Attached patch 1.8 branch patchSplinter Review
Attachment #263158 - Flags: approval1.8.1.4?
Attachment #263158 - Flags: approval1.8.0.12?
Neil, Ctho, you might want an equivalent in Seamonkey.
Attached patch Suite trunk portSplinter Review
Attachment #263206 - Flags: review?(cst)
Comment on attachment 263208 [details] [diff] [review]
Branch version of attachment 263206 [details] [diff] [review]

Please include more lines of context.
Attachment #263208 - Flags: review?(cst) → review+
Comment on attachment 263208 [details] [diff] [review]
Branch version of attachment 263206 [details] [diff] [review]

a=me for 1.1.2
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
Suite fixes checked in.
Comment on attachment 263158 [details] [diff] [review]
1.8 branch patch

approved for 1.8.1.4, a=release-drivers
Attachment #263158 - Flags: approval1.8.1.4?
Attachment #263158 - Flags: approval1.8.1.4+
Attachment #263158 - Flags: approval1.8.0.12?
Attachment #263158 - Flags: approval1.8.0.12+
checked into 1.8 and 1.8.0 branches
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

This appears to be the issue described by CVE-2007-1004
Alias: CVE-2007-1004
You need to log in before you can comment on or make changes to this bug.