Closed Bug 561482 Opened 14 years ago Closed 13 years ago

Switching tabs in a popup with a readonly locationbar doesn't update the locationbar (spoofing)

Categories

(Firefox :: Tabbed Browser, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- -
status1.9.2 --- unaffected

People

(Reporter: djcater+bugzilla, Assigned: dao)

References

Details

(Keywords: regression, Whiteboard: [fixed by bug 642355][sg:moderate][URL+SSL spoof after a little interaction][Details in comment 8])

Attachments

(5 files, 3 obsolete files)

Websites can be spoofed (locationbar, padlock and identity indicator all false positive) using popups with readonly locationbars. This involves creating more than one tab in the popup, and causing the browser to switch to a background tab. Proof of concept and description coming up.
Attached file Page 3, required by page 2 (obsolete) —
Required for proof of concept
Attachment #441188 - Attachment is obsolete: true
Attached file Page 3, required by page 2 (obsolete) —
Required for proof of concept. Had to change it slightly to work being served from Bugzilla.
Attachment #441189 - Attachment is obsolete: true
Attached file Page 3, required by page 2 (obsolete) —
Required for proof of concept. Trying again to deal with Bugzilla query parameters.
Attachment #441191 - Attachment is obsolete: true
Proof of concept page 3. Gave up trying to make it work with bugzilla, you'll have to use a bit of creativity to imagine a better finale.
Page 2 of the proof of concept.
Attached file Page 1, start here
Page 1. This is the first page of the proof of concept. Start here.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100423 Minefield/3.7a5pre

OK, that appears to work now, just with a slightly less technical ending.

Load page 1 (doesn't matter where, new tab will be easiest) using the latest nightly and then follow the instructions (and try and act a bit more naive than browser engineers :-)

What you should end up with is a very fake PayPal page which according to the locationbar and identity button is at https://www.paypal.com/ and has a valid EV certificate, but which is actually hosted here on Bugzilla (serving from a non-https site would also spoof the padlock).

Notes and details coming shortly.
Page 1 opens page 2 in a popup with location=0 and keeps a reference to it.

It opens it at the same position and size as itself.

It then polls the new window to see if it has been navigated to a new page yet (this was a bit tricky, as permission is denied to read the location of a page when it has changed to a different domain, and this is not thrown as a catchable exception). I left the debugging statements on the page.

Page 2 then asks the user to agree to 3 statements, but implements them as options in a select with multiple selections. This is so that the user can be persuaded to Ctrl+click on a hidden link, forcing a new tab to be created. (I tried synthesizing middle-clicks and Ctrl-clicks but that was fixed in bug 265176. I also tried spawning popups from this popup, and using target= but I couldn't get a new tab to be created in the same window.) The link surrounds a transparent PNG which covers the 3rd option element. It's outline is hidden, it's cursor is set to default and it has no href initially so that the statusbar doesn't display anything. onmousedown it acts as if the underlying option was clicked and appropriately selects or deselects it. onmouseup it sets the href to page 3 (so the Ctrl+click causes that page to load in a new tab) and sets the location to https://www.paypal.com/ before returning false.

So we now have 2 tabs in the popup, although there is no tab bar and the background tab is hidden. The background tab is page 3 (the fake PayPal) and the current tab is loading the real PayPal. As it starts to load, page 1 will not be able to read its location, so it knows that the user has now clicked on the hidden link.

Page 1 now calls window.close() on the tab that is loading the real PayPal. This causes it to close, and therefore the background tab becomes the active tab. However, the locationbar has already changed to https://www.paypal.com/ and the identity indicator shows a valid EV certificate and changing to the other tab has not updated either of them. Voilà, fake PayPal with real PayPal indicators.

At this point page 1 then disappears via location.replace("about:blank"). Page 3 then steals the username and password (this bit doesn't really work with my concept here on bugzilla, but it's trivial from here), pretends that the user has entered them incorrectly, and redirects itself to the real PayPal. There are now no pages left open from the attacking site, and the credentials have been stolen.
Note that PayPal has been a bit slow today, and I think this might not work so well if the document.location changes before the EV has appeared, but I'm not sure.

The main change that allowed this was bug 470051 but I think there are underlying issues too. Right-clicking on the fake page and choosing Page Info leads to a mismatch between the location it shows and the security details it shows. I've also managed to get the browser into a state where the locationbar shows the fake URL but the identity indicator is for PayPal so they are out of sync. This shouldn't happen.

If it's been decided that there should be no tabbar in location=0 popups (which probably makes sense) then there should be no methods available to open new tabs. Context-menu, middle-click, Ctrl-click and if menubar=1 is added to the window.open() then there are loads more (bookmarks, Release Notes). If you play around with menubar=1,location=0 popups you can really get the tab browser in a confused state.

If there's anything I can do to help out, please let me know.
Whiteboard: Details in comment 8
Whiteboard: Details in comment 8 → [sg:moderate][URL+SSL spoof after a little interaction][Details in comment 8]
I don't think this blocks the release, but I'd like to get clearer on how automatic this attack could be made. I would *certainly* like to get it fixed.

Is there an easy way to implement daniel's suggestion in comment 9, or does it mean tracing 74 code paths?
blocking2.0: ? → -
Note that part of this bug has now been discovered in bug 586234, but only the part about being able to open new tabs and not the problems or security implications that come with switching between them.

I have looked into ways to make this require less user interaction, but the current code is the best that I have come up with (using Ctrl+click on a <select> as a way to get the user to open a new tab).

Other ways include:

Persuading the user to press Ctrl+Enter.
Persuading the user to middle-click.
Persuading the user to right-click -> Open Link in New Tab (!)
Scripting Ctrl+click, Ctrl+Enter or middle-click (can't seem to get this to work due to bug 265176 being fixed).

Note that bug 395917 basically argues for that bug to be WONTFIXed.

Are there any ways that I've missed of opening a link in a new tab? Targeting links into new _windows_ (via window.open or the target attribute) won't load a new tab in this particular window because of the following code in nsBrowserGlue.js which skips over chromehidden windows:

1251   getMostRecentBrowserWindow: function BG_getMostRecentBrowserWindow() {
1252     function isFullBrowserWindow(win) {
1253       return !win.closed &&
1254              !win.document.documentElement.getAttribute("chromehidden");
1255     }
With a well-designed page and the right wording, users can be persuaded to do many things. For example, I mentioned in bug 305692 some Facebook pages that have duped tens of thousands of people into following steps that tell them to press certain key combinations in order to reveal an image. The pages don't even try and trick them into it, they just plain ask them to. Using Ctrl+Enter on a pre-focused link as one of the key combinations in this trick would work with this bug.

Selecting multiple options in a select by using Ctrl+click is also something that I have seen webpages ask users to do before.

This bug doesn't have to have the user open the hidden tab at the same time as taking them to the attack page. The hidden background tab could be opened at some point, and then later on the current tab could be navigated to the site-to-be-spoofed and closed using a much more common user interaction, like left-clicking on a link. The initial part could be done as part of a game, or part of a Facebook page.

I therefore think that this would exceed the 10% of users given as a guide here: https://wiki.mozilla.org/Security_Severity_Ratings

"As a rough guide, to be considered for reduction in severity an exploit should execute successfully less than 10% of the time. If measures can be taken to improve the reliability of the exploit to over 10% (by combining it with other existing bugs or techniques), then it should not be considered to be mitigated."
But then I would say that, because $500 would be handy ;-)

That aside (it's not why I filed the bug), I think given that this has been partly discovered elsewhere, that it has now been shipped in beta builds as opposed to nightlies only, and that web users have been show to do anything that a web page tells them to, I think that this should be upgraded.

Bug 485237 may help.
Quickly skimming security bugs:

I can't seem to reproduce this on trunk. Perhaps a new testcase is needed?

What's the brief summary of what's happening here? Do one of the previous extensive comments cover this?
(In reply to Justin Dolske [:Dolske] from comment #14)

This was mainly fixed / wallpapered over by bug 586234, and other similar cases were fixed in bug 606678, bug 642355 and bug 593687. Bug 610203 is still open.

My concern is that these fixes were each covering one way of opening a new tab in a popup window, and that there may be others now or in the future. The underlying spoofing issue of the location bar and identity indicator mismatching the actual location was never specifically addressed. Perhaps some more robustness could be added.

I don't know if bug 485237 is still relevant but I think that there is probably some work that could be done there.

Bug 470051 was what initially allowed this spoofing to be possible.

Some tests to check that new tabs cannot be opened in popups with a readonly location bar would be good, covering all ways of opening a new tab.
Blocks: 470051
Flags: in-testsuite?
Assignee: nobody → dao
Bug 642355 fixed this. The errors you see there (e.g. bug 642355 comment 2) are what prevented the location bar from updating.

Bug 470051 didn't actually cause this.
No longer blocks: 470051
Status: NEW → RESOLVED
Closed: 13 years ago
status2.0: ? → ---
Depends on: 642355
Resolution: --- → FIXED
(In reply to Dão Gottwald [:dao] from comment #16)
> Bug 642355 fixed this. The errors you see there (e.g. bug 642355 comment 2)
> are what prevented the location bar from updating.
> 
> Bug 470051 didn't actually cause this.

My mistake, I first discovered this bug when testing the fix for bug 470051 so I mistakenly thought it was the cause of this bug. You're right that it isn't; I've just gone back and checked using nightlies and the regression range is:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=050887c64183&tochange=16a974dd72e1

which suggests bug 347930 was the cause (2010-03-17).

As for the fix, I don't think it was bug 642355 as you say, because the bug still existed after that fix (2010-04-01) right through to October 2010. This was fixed within this range:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=733280bfc136&tochange=094d838ed780

which points to bug 586234 (2010-10-24).
Blocks: 347930
Depends on: 586234
No longer depends on: 642355
Just adding a couple of screenshots of what the spoof looked like for posterity.
Dão, I have a few closing questions, just to make sure that everything is covered here.

1. Is there anything that can be done to make the connection between the tab content and the location chrome more robust? Bug 586234 stopped this bug from working, obviously, but by opening the second popup in a different window. It didn't directly address the issue of two tabs being open in one popup window, just wallpapered over one of the ways in which it can happen (followed by bug 606678, bug 642355, bug 593687 and bug 610203 fixing some other ways).

2. Is bug 485237 still valid?

3. Are there any automated tests that cover this bug? There were no tests checked in for this bug, bug 347930, bug 642355 or bug 586234. If so, are there any more that can be added to test more things?

4. Can this bug be opened up now?

Thanks.
bug 642355 was fixed in 2011.
Depends on: 642355
No longer depends on: 586234
Whiteboard: [sg:moderate][URL+SSL spoof after a little interaction][Details in comment 8] → [fixed by bug 642355][sg:moderate][URL+SSL spoof after a little interaction][Details in comment 8]
> 2. Is bug 485237 still valid?

Yes, but it doesn't affect this bug.

> 3. Are there any automated tests that cover this bug? There were no tests
> checked in for this bug, bug 347930, bug 642355 or bug 586234. If so, are
> there any more that can be added to test more things?

Even though we provide no UI to opening tabs in popups, a test could programmatically open a tab in a popup.

> 4. Can this bug be opened up now?

What for?
(In reply to Dão Gottwald [:dao] from comment #21)
> bug 642355 was fixed in 2011.

Yes, my mistake again. However, this spoof definitely stopped working in the 2010-10-24 nightly, so this bug was fixed before then. Are you saying that had bug 586234 not been fixed, bug 642355 would also have fixed this bug?

These were the errors for this bug, the first of which does correspond with one of the errors in bug 642355.

Error: newBrowser is undefined
Source File: chrome://browser/content/tabbrowser.xml
Line: 754

Error: this.selectedTab is null
Source File: chrome://browser/content/tabbrowser.xml
Line: 1546

(In reply to Dão Gottwald [:dao] from comment #22)
> > 4. Can this bug be opened up now?
> 
> What for?

By opened up I meant opened up to the public, not reopened. The introduction and fix for this both occurred during the Firefox 4 timeline (appeared in alpha 4, fixed in beta 8). Bug 642355 was fixed in Firefox 5. I thought security bugs with shipped fixes were usually opened up?
Depends on: 586234
No longer depends on: 642355
Depends on: 642355
(In reply to Daniel Cater from comment #23)
> (In reply to Dão Gottwald [:dao] from comment #21)
> > bug 642355 was fixed in 2011.
> 
> Yes, my mistake again. However, this spoof definitely stopped working in the
> 2010-10-24 nightly, so this bug was fixed before then. Are you saying that
> had bug 586234 not been fixed, bug 642355 would also have fixed this bug?

Yes, see comment 16. Bug 642355 fixed the underlying problem.

> By opened up I meant opened up to the public, not reopened. The introduction
> and fix for this both occurred during the Firefox 4 timeline (appeared in
> alpha 4, fixed in beta 8). Bug 642355 was fixed in Firefox 5. I thought
> security bugs with shipped fixes were usually opened up?

I lack the privilege to change this, but sure, there's no reason to keep this private.
Group: core-security
Keywords: regression
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: