529594 - (CVE-2009-4129) Mozilla Firefox local file Popup Message Spoofing Vulnerability (TSA-20091117-006)

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Reed Loden [:reed]]

Received the following advisory today at security@. Not really sure what component it would fall under, so filing it under Core :: General for now.

==========================================================================

+------------------------------------------------------------------------+
| TOPSEC SECURITY RESEARCH LAB                         November 17, 2009 |
| http://www.topsec.com.cn                              TSA-20091117-006 |
|                                                                        |
| Product: Firefox                                                       |
| Summary: Popup message spoofing.                                       |
+------------------------------------------------------------------------+

BACKGROUND
----------
  Firefox is Mozilla Foundation's open source web browser application. More 
  information is available at the following website:
  
  http://www.mozilla.com/firefox/

OVERVIEW
--------
  Firefox v3.5.5 is prone to popup message spoofing contained inside a web 
  page on another domain.
  
  Popup message spoofing can be done by a mismatch of URL in the browser 
  address bar and the true origin of popup message . A real exploitation of 
  this issue is in the following scenario: When a user opens the malicious 
  web page using Firefox v3.5.5 will see address(example: digg.com) but 
  when popup message is displayed, the displayed popup message could be 
  from another domain, not the address shown(digg.com).
  
  An attacker can use this vulnerability in order to hide his address and 
  perform social engineering attacks to perform a successful Internet user 
  targeting attack.
  
WORKAROUND
----------
  Although it is not widely viewed as a viable workaround, disabling 
  scripting can prevent exploitation of this vulnerability. The following 
  steps explains how to disable this setting on Firefox 3.

    1. From the "Tools" menu, select "Options"
    2. Navigate to the "Content" settings.
    3. Ensure that "Enable JavaScript" is not checked.

Comment 5

[Reed Loden [:reed]]

Hmm, I'm not seeing "[JavaScript Application]" as my window title. I see "The page at https://bug529594.bugzilla.mozilla.org says..." Maybe I need to run these locally? I'll test that.

Comment 6

[Reed Loden [:reed]]

Indeed. If I run the testcase locally (and have it point to a local file), I get "[JavaScript Application]" as the window title.

Comment 8

[Reed Loden [:reed]]

No difference between absolute or relative URL. I seem to only be able to get "[JavaScript Application]" when the files are local to my machine. I have one more thing to test just to make sure the attachment redirect isn't causing problems.

Comment 9

[Reed Loden [:reed]]

Nope, still getting a title that says "The page at <url> says:" even when accessing the files without some type of redirect.

Comment 10

[Daniel Veditz [:dveditz]]

This is not exploitable from the web where we clearly show the host name that originated the prompt. We don't for local files -- for prompts from a hostless source we use the old generic script title. At the time we weren't all that worried about downloaded malicious files, but it wouldn't be hard to change the title to say it's a local source. Even then there's spoofing risk because people read the dialogs and not the titles, but you can only do so much.

Leaving this open in case we want to change prompt titles for hostless sources, but it doesn't need to be a hidden security bug.

Comment 11

[Jesse Ruderman]

I disagree with comment 10.  I think it's a bug that the evil page can make a popup appear directly above a page from another domain, and I don't think the "host X says:" really saves us.

If we want to change prompt titles for hostless sources, that should be a separate bug.

Comment 12

[Daniel Veditz [:dveditz]]

Where is it coming up from a different domain? In the examples here it's all the same domain and that doesn't seem to be the trick they're trying to pull.

Are you saying that a cross-origin frame/plugin should not be allowed to use alert/prompt/confirm ever? That's maybe worth persuing (though it will have some collateral damage), but I didn't think that's what this bug is about.

Comment 13

[Daniel Veditz [:dveditz]]

Ah, the joys of a high latency connection. I dismissed the prompt over a blank page (with the URL bar still saying bugzilla) before any digg content came up.

Comment 14

[Daniel Veditz [:dveditz]]

So what you really want is that the prompt service should fail if the page is already navigating, or the modal dialog should suspend/cancel the navigation.

Comment 15

[tcphttp]

I'm with Jesse. Window title is a mitigation, but address bar is primary, for determining URL.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

Given that we have now tab specific prompt/alert/etc, this should be WFM.
Can't reproduce the problem.

Marking WFM, please reopen if you see still some issue.