Mozilla firefox vulnerability!

extermination · Post by **extermination** » July 30th, 2004, 7:15 am

Mozilla / Mozilla Firefox User Interface Spoofing Vulnerability
Secunia Advisory: SA12188 Release Date: 2004-07-30
Critical: Moderately critical
Impact: Spoofing
Where : From remote

Software:Mozilla 0.x
Mozilla 1.0
Mozilla 1.1
Mozilla 1.2
Mozilla 1.3
Mozilla 1.4
Mozilla 1.5
Mozilla 1.6
Mozilla 1.7.x
Mozilla Firefox 0.x

Choose a product and view comprehensive vulnerability statistics and all Secunia advisories affecting it.
Description:
A vulnerability has been reported in Mozilla and Mozilla Firefox, allowing malicious websites to spoof the user interface.

The problem is that Mozilla and Mozilla Firefox don't restrict websites from including arbitrary, remote XUL (XML User Interface Language) files. This can be exploited to "hijack" most of the user interface (including tool bars, SSL certificate dialogs, address bar and more), thereby controlling almost anything the user sees.

The Mozilla user interface is built using XUL files.

A PoC (Proof of Concept) exploit for Mozilla Firefox has been published. The PoC spoofs a SSL secured PayPal website.

This has been confirmed using Mozilla 1.7 for Linux, Mozilla Firefox 0.9.1 for Linux, Mozilla 1.7.1 for Windows and Mozilla Firefox 0.9.2 for Windows. Prior versions may also be affected.

NOTE: This issue appears to be the same as Mozilla Bug 244965.

Solution:
Do not follow links from untrusted sites.

Provided and/or discovered by:
Reported in Mozilla Firefox by:
Jérôme ATHIAS (also created a PoC)

Reported in Mozilla by:
James Ross

Changelog:
2004-07-30: Added an additional Mozilla Bug reference.

Original Advisory:
Original Advisory and Proof of Concept:
http://www.nd.edu/~jsmith30/xul/test/spoof.html

Other References:
XUL Documentation:
http://www.xulplanet.com/

Mozilla Bug reference:
http://bugzilla.mozilla.org/show_bug.cgi?id=244965

Mozilla Bug reference:
http://bugzilla.mozilla.org/show_bug.cgi?id=252198

Please note: The information, which this Secunia Advisory is based upon, comes from third party unless stated otherwise.

Secunia collects, validates, and verifies all vulnerability reports issued by security research groups, vendors, and others

scratch · Post by **scratch** » July 30th, 2004, 11:35 am

this was already posted here. the problem is, no one's sure how to fix it, because it's a feature rather than a bug. no, honestly!

Robert S. · Post by **Robert S.** » July 30th, 2004, 12:32 pm

http://bugzilla.mozilla.org/show_bug.cgi?id=244965

is resolved fixed and I verified it against the test case with 7/29 branch

brianstop · Post by **brianstop** » July 30th, 2004, 12:41 pm

Wig,
resolved? Evidently not for me--I haven't heard about a patch or any official word about how the user would address the problem. Did I miss this? Can it really be resolved if this isn't in place?

Fixed? Same problem. For who? People who compile their own browsers? People who beta-gamble on nightly builds?

Seriously--what does "resolved" mean to Mozilla--anyone? What does "fixed" mean? I think the answer will reveal who Mozilla's target audience really is.

Where's the official news on what Joe User is supposed to do? I don't doubt it exist if the problem is resolved and fixed--just want to know where it is.

Lost User 15175 · Post by **Lost User 15175** » July 30th, 2004, 1:39 pm

I'm using the official 07/29 Branch and I still get the spoof. It's not fixed for me.

Robert S. · Post by **Robert S.** » July 30th, 2004, 1:41 pm

brianstop - you are entirely correct in relation to your definition of resolved fix... I used those terms in the context of bugzilla which was the context I was speaking from. Outside of bugzilla in relation to the systems running Mozilla receiving a patch, no it has not been resolved.

I hope you are able to understand the difference... and as for understanding bugzilla's resolved fix status this doesn't appear to be what you would like but if you would like to understand what those terms mean you can always read up on bugzilla.

Robert S. · Post by **Robert S.** » July 30th, 2004, 1:50 pm

Are you still seeing it becasue this one is still open?

http://bugzilla.mozilla.org/show_bug.cgi?id=252198

Blake · Post by **Blake** » July 30th, 2004, 1:50 pm

This is not a vulnerability. The same thing can be accomplished in Internet Explorer, Opera and every other browser with some skill and know-how.

c0Ld · Post by **c0Ld** » July 30th, 2004, 2:01 pm

It didn't look at all like my user interface when I opened the page. The icons were large, it was set to the default theme, and nothing worked correctly, includeing all of the menus, not to mention my bookmarks toolbar wasnt there. Who would fall for that?!

jimdude · Post by **jimdude** » July 30th, 2004, 2:06 pm

This might not be a vulnerability, bug, miscalculation, or design flaw, but is it desirable? I hate it when some site changes the user interface that I've so carefully taylored to my preferences. In a standalone program I can accept someone elses user interface, but on a web browser, which is after all supposed to be a "browser" is there really any reason open the user interface for outside manipulation? IE does this because MS believed that they are God. Is Mozilla constrained to following the bad decisions from Bellview?

Racer · Post by **Racer** » July 30th, 2004, 2:25 pm

jimdude: The UI changing part (such as removing the URL bar, menu bar, status bar, etc) can be done with a simple JS statement in Mozilla, IE, and any other browser out there. Effectively, if you open a new browser window, the original bars will be back to normal again. If you want to keep sites from removing those various "bars", you can very easily change the dom.disable* prefs that you want. After this, Mozilla will prevent sites from removing the bars, thus making the potential exploit nonexistant.

The problem with the bug from this topic is that most people have not set the above prefs. So, after the website has removed all of those bars, it then loads the content of the page with something that tries to look like the removed bars so that you think they haven't been removed. This can be done almost as easily in XUL as it can with HTML, so therefore can happen on any browser.

There have been various solutions to this problem, however I think the easiest (and something I did a LONG time ago) was what I just stated: make the menubar (and perhaps the URL bar as well) unhideable via the prefs.

jimdude · Post by **jimdude** » July 30th, 2004, 5:15 pm

And why wasn't the preference defaulted to "leave my menu bars along!" Probabaly because the default in IE was to allow the bars to be removed, and MS did that so they could integrate IE into the OS without people realizing that it was IE that was displaying informaion. Does Mozilla have the same reason?

scratch · Post by **scratch** » July 31st, 2004, 12:00 am

of course not. mozilla has it because it's (i assume) in the emcascript standard.

mart44 · Post by **mart44** » July 31st, 2004, 12:26 am

Regarding the preferences that need changing to stop the bars being altered. Are these the ones found in: Tools > Options > Web Features > Advanced. Then you untick the boxes in the Advanced JavaScript Options?

I really looked in to see if there was any comments to be read about this (link below) that I came across on my travels. I know it's a different issue but it comes under the same heading, so I hope it's OK to add it to the thread. I sounds as if it's being worked on anyway.

http://news.com.com/Mozilla+to+squash+s ... 86138.html

michaell522 · Post by **michaell522** » July 31st, 2004, 4:44 am

Blake wrote:This is not a vulnerability. The same thing can be accomplished in Internet Explorer, Opera and every other browser with some skill and know-how.

True, but that doesn't mean that something shouldn't be done.

Disallowing hiding of the status bar sounds like a good thing (and IE is doing that). Won't solve it, but it will mean that action has been taken, which is important from a perception point of view.