The default bug view has changed. See this FAQ.
Bug 370555 (CVE-2007-1004)

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

RESOLVED FIXED

Status

()

Firefox
Security
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: Michal Zalewski, Assigned: dveditz)

Tracking

(4 keywords)

unspecified
fixed-seamonkey1.0.9, fixed-seamonkey1.1.2, verified1.8.0.12, verified1.8.1.4
Points:
---
Bug Flags:
blocking1.8.1.4 +
blocking1.8.0.12 +

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(5 attachments)

(Reporter)

Description

10 years ago
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.

Updated

10 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 1

10 years ago
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.
(Assignee)

Updated

10 years ago
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...
(Assignee)

Updated

10 years ago
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...

Comment 4

10 years ago
(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?

Comment 7

10 years ago
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

10 years ago
Is #2 from included in this discussion? If not, has anyone submitted a bug about it?

Comment 9

10 years ago
*edit: From http://lcamtuf.coredump.cx/fftests.html
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.
(Assignee)

Comment 11

10 years ago
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.
(Reporter)

Comment 12

10 years ago
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

10 years ago
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

10 years ago
(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

10 years ago
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?
(Reporter)

Comment 16

10 years ago
(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'.
(Reporter)

Comment 17

10 years ago
(In reply to comment #16)
> probably wouldn't hurt to make it visible and maybe default to 'false'.

err, 'true'.


Comment 18

10 years ago
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

10 years ago
> 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

10 years ago
(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

10 years ago
(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

10 years ago
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

10 years ago
This causes the regression when homepage is left unfilled (or about:blank). Everytime i start the browser it goes to the "firstrun" page.
(Assignee)

Comment 24

10 years ago
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

10 years ago
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

10 years ago
Is Dan's method the general consensus as being the best way to fix this?
(Assignee)

Updated

10 years ago
Assignee: nobody → dveditz
Flags: blocking1.8.1.4?
Flags: blocking1.8.1.4+
Flags: blocking1.8.0.12?
Flags: blocking1.8.0.12+
(Assignee)

Updated

10 years ago
Attachment #255442 - Flags: review?(mconnor)
(Assignee)

Updated

10 years ago
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+
(Assignee)

Comment 28

10 years ago
Checked in on trunk with requested changes
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [sg:low spoof] need r=mconnor (still) → [sg:low spoof] need branch approval
(Assignee)

Comment 29

10 years ago
Created attachment 263158 [details] [diff] [review]
1.8 branch patch
Attachment #263158 - Flags: approval1.8.1.4?
Attachment #263158 - Flags: approval1.8.0.12?
Neil, Ctho, you might want an equivalent in Seamonkey.

Comment 31

10 years ago
Created attachment 263206 [details] [diff] [review]
Suite trunk port
Attachment #263206 - Flags: review?(cst)

Comment 32

10 years ago
Created attachment 263208 [details] [diff] [review]
Branch version of attachment 263206 [details] [diff] [review]
Attachment #263208 - Flags: review?(cst)

Comment 33

10 years ago
Created attachment 263209 [details] [diff] [review]
1.8.0.x version of attachment 263206 [details] [diff] [review]
Attachment #263209 - 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+
Attachment #263206 - Flags: review?(cst) → review+
Attachment #263209 - Flags: review?(cst) → review+

Comment 35

10 years ago
Comment on attachment 263208 [details] [diff] [review]
Branch version of attachment 263206 [details] [diff] [review]

a=me for 1.1.2

Comment 36

10 years ago
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

10 years ago
Suite fixes checked in.
Keywords: fixed-seamonkey1.0.9, fixed-seamonkey1.1.2
(Assignee)

Comment 38

10 years ago
Comment on attachment 263158 [details] [diff] [review]
1.8 branch patch

approved for 1.8.1.4, a=release-drivers
(Assignee)

Updated

10 years ago
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+
(Assignee)

Comment 39

10 years ago
checked into 1.8 and 1.8.0 branches
Keywords: fixed1.8.0.12, fixed1.8.1.4
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

Keywords: fixed1.8.0.12, fixed1.8.1.4 → verified1.8.0.12, verified1.8.1.4
(Assignee)

Updated

10 years ago
Duplicate of this bug: 390627

Updated

10 years ago
Duplicate of this bug: 402060
(Assignee)

Comment 43

9 years ago
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.