Closed Bug 252198 Opened 20 years ago Closed 20 years ago

weak XUL security allows chrome UI spoofing ("phishing" attack)

Categories

(Firefox :: General, defect, P1)

Product:
Firefox
Component:
General
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 22183

People

(Reporter: jeff, Assigned: bugzilla)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8

Firefox's chrome UI is written entirely in XUL.  Because of this, a website can have embedded XUL that spoofs the UI.  For an example, see the demo at
http://www.nd.edu/~jsmith30/xul/test/spoof.html

I don't know a solution to this problem.  Perhaps we can put some more limitations on remote XUL (a la the popup blocker).  Or perhaps we can make the status bar always-on.  For a little more discussion, see:
http://forums.mozillazine.org/viewtopic.php?t=102334


Reproducible: Always
Steps to Reproduce:
1.  Go to any site with some deceptive XUL files
2.  Enter credit card number
3.  p0wnd!
Actual Results:  
The default installation of Firefox will display a spoofed login page so real that even seasoned Firefox users will have trouble seeing the evil.

Expected Results:  
Some sort of warning, or some behavior that prevents such a complete takeover.  Firefox should be safe out-of-the-box, because people who don't know how to detect a phishing scam are the same people who don't know how to turn on security options.

Note that this works in all 0.9 versions of Firefox up to today's nightly, on (probably) all platforms, with (probably) all themes.

Because other websites can make use of the chrome:// protocol, the bad guy's job is made much easier; very few files are actually downloaded from the bad webserver.  In addition, chrome:// allows the spoof to be "theme-aware".

The "allow javascript to hide the statusbar" option is also on by default.  It shouldn't be.
Confirmed, scary...
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
->IMO it's at least critical
Severity: major → critical
Flags: blocking-aviary1.0RC1?
How about a whitelist for known "good" sites (ex. mozilla.org, mozdev, paypal,
ebay, amazon, etc etc.), they would be able to use the chrome:// protocol, other
sites could be added by the user.

Or we could follow the same route as we did with the xpi install mechanism and
present the user with some sort of warning. (DNS cross reference?)
Asking the user isn't secure. How much people enables everything in IE just to be able to have access to all features? We can't count on asking users if they want a secure browser or a feature browser: they will always choose the feature browser and complain after that it isnt secure (just after beiing stoled its credit card info...)

Maybe a white list could do it... It should be well hidden though. Not many people needs this.

Just to keep the bug updated with the discussion in the thread...

Someone pointed out that XUL isn't necessary - the same thing can be achieved
with HTML (and produced a demo at
http://www.pikey.me.uk/mozilla/test/spooftest.html ).

That demo uses images from chrome://, but those could of course be copied and
served from the site (although you'd only be able to spoof the default theme)

I don't see a solution to this, aside from making some part of the UI unhideable
so spoof windows at least have a dual status bar or URL bar. I don't know if
there's a bug for that yet...
What about making a location of FF transparent?? It could be a bit like those
holograms on credit cards (visa).

Making the spinning icon transparent? If you can see thrue, than icons would be
originals...
(In reply to comment #6)
> What about making a location of FF transparent??

There's a new CSS3 property called "opacity" that is supported by Moz 1.7+ and FFX 0.9+ ...

Here is what the problem boils down to.  The SSL architecture guarantees us that
we know when we're talking with "Paypal, Inc."  The problem is in Firefox
indicating this to the user.  Since html can also be used to do spoofing, just 
limiting XUL isn't enough.  Here are some options:

1) Force some UI to always be present, or put it where the bad guy can't get to it.
    For example, put the padlock in the title bar of the app.
2) Introduce some per-user UI randomness so that a spoofer doesn't know what to spoof
3) Do some type of warning for each new domain that the user tries to sumbit a html form to
    "Warning - you are about to submit information to www.paypal-spammerfish.com.  Make sure that
    you trust this domain.  Do you want to continue?"
   (Power users will know how to turn this off; it'll be our little secret.)
4) Change the FFX logo to a spinning 'e'...

Some non-solutions that would at least help the matter a lot:
1) Limit XUL some more.  Put up warnings, or whitelists, or something.
2) Limit chrome:// some more.  Put up warnings, or whitelists, ....
IMO, it makes more sense to keep the address bar always on than to keep the
status bar always on.

Status bar always on:
* Web site can't spoof an encrypted connection.
* Web site can't spoof update notification in order to trick you into installing
malware.

Address bar always on:
* Web site can't make itself look like a native application.  It's clear that
the window is a web browser content window.
* Address is visible, so you know what site you're on.  This is much more
important than knowing whether the connection is encrypted and/or authenticated.
* Web site can't spoof an encrypted connection (Firefox only).

Anyway, this is a dup of bug 22183.
If it's a dupe, then unless bug 22183 has some details which don't appear in
this bug and/or the Mozillazine thread, it could be opened and this bug duped, no?

For the status bar/URL bar not being hideable - that should be a separate bug.
Is there one yet (I know it's been mentioned in other bugs)?
Comments 76 through 84 in bug 22183 are a debate over whether to make it public :/

> For the status bar/URL bar not being hideable - that should be a separate bug.

What is this bug about, then?
(In reply to comment #10)
> Comments 76 through 84 in bug 22183 are a debate over whether to make it public :/
> 
> > For the status bar/URL bar not being hideable - that should be a separate bug.
> 
> What is this bug about, then?

This bug is about security issue of XUL UI. If it includes non-hidding of the
address bar, then I don't see why we should open another bug...
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0+
Priority: -- → P1
I don't think I've seen this idea mentioned before, so here's another way to
limit the success rate for UI spoofing attacks: on installation (or first launch
in new profile), create some randomness to the UI (different colors, gradients,
fractal image variations of common icons etc.). That way everyone's program
would look slightly different, enabling smart users to realize when they are
viewing a scam. The variations should not be made available to remote chrome.

Of course I'd like all my Mozilla installations to look the same, so the
"randomness" could be asked from the user during installation and if you wanted
the same UI mods you would supply the same information on each install.
Bug 245406 is relevant to this discussion.

Gerv
Why do we allow content to window.open or otherwise use chrome: URLs?

Don't we forbid file: URLs from being loaded into windows or frames from
non-file:  non-chrome: documents?

/be
Depends on: 252811
This is pretty serious.

Disallowing remote XUL by default and asking whether the user wants to enable it
"for this site" and doing the same for access to the chrome: URLs seems only
sensible. Also requiring the address bar and relevant chrome to be displayed
ALWAYS unless the user says otherwise.
like comment #5 said: this has nothing to do with XUL in itself

somebody could fake firefox , MSIE or whatever wit a little effort using plain HTML

use MSIE to try the simple example at http://ja-web.de/tmp/iefake/

the UI does not work but how many unexperienced people will notice before they
klick the login button?


We have a pref for not allowing js to hide the statusbar (something WinXP Sp2
will do for IE) - we could default it to true.

Also, we could make non-chrome documents not be able to resize/open windows
larger than the screen (to move the statusbar offscreen) - don't we have that
functionality already?
Brendan: if we didn't allow non-chrome XUL to reference chrome urls, people
could just hardcode the menuitems in their XUL and not use the chrome entities
as they did in that spoof url.
Defaulting the pref for disallowing removal of the status bar was filed as bug
252811 (which is currently marked as blocking this bug)
*** Bug 253745 has been marked as a duplicate of this bug. ***
I think always showing the status bar is in fact the right thing to do (unless
the window is using the "chrome" flag, which requires expanded priveleges to use).
Bug referenced in a Secunia Advisory: http://secunia.com/advisories/12188/
Another solution would be to manage a list of host where the user can send
POSTDATA to (just like the popup host list).

This would not prevent the spoofed window but it would prevent the harm from
being done: when the user click on send, a windows pops up informing him of the
*actual* destination of the information, all risk associated and ask him whether
to allow the POSTDATA request or not.

This could work for all form of phishing.

Hope this help
(In reply to comment #16)
> like comment #5 said: this has nothing to do with XUL in itself
> 

The reason I see this as being more serious than spoofing the UI with a jpeg is
because the result is far more realistic.  Furthermore, if you know half a thing 
about XUL, it's actually -easy- to do this; most of the hard XUL work has
already been coded for you and can be copy/pasted from the chrome folder.  All
you have to do is modify a couple things.

(In reply to comment #23)
> Another solution would be to manage a list of host where the user can send
> POSTDATA to (just like the popup host list).

Unfortunately, this will not work, as you can bypass the <form> tag entirely, by
using some javascript to roll your own URL into a GET request.

(In reply to comment #17)
> Also, we could make non-chrome documents not be able to resize/open windows
> larger than the screen (to move the statusbar offscreen) - don't we have that
> functionality already?

Is that supposed to be guaranteed?  On Windows XP, I can't make a window appear
partially offscreen with window.open(), but on my GNOME Linux desktop, I can.
IMO the right solution to this is to change the default so that JS popup
windows must have a Location bar AND a status bar.

Either of these is technically enough to make the spoof imperfect, but
the two together make it *really* clear that this is a browser window.

Let's be secure by default:

user_pref("dom.disable_window_open_feature.location", true);
user_pref("dom.disable_window_open_feature.status" , true); 

The settings of comment #25 make it indeed very clear that something is wrong,
however Joe User will not understand that it's in fact a malicious website
trying to trick you. He will rather think that it's a kind of bug of Firefox or
something like that.  So these prefs are a start, but they certainly are not
sufficient.
(In reply to comment #25)
> IMO the right solution to this is to change the default so that JS popup
> windows must have a Location bar AND a status bar.
> 
> Either of these is technically enough to make the spoof imperfect, but
> the two together make it *really* clear that this is a browser window.

In addition to that the URLs in location & status bar should be 
syntax-highlighted, possibly warning the user if it contains any of the classic
www.fake.com\cgi-bin\****@12345678/?id=123 -type URLs.
> In addition to that the URLs in location & status bar should be 
> syntax-highlighted, possibly warning the user if it contains any of the classic
> www.fake.com\cgi-bin\crap@12345678/?id=123 -type URLs.

The status bar only contains the hostname - none of the other stuff in the URL -
that's the point of having that text in the status bar. Also, there is now a
warning for URLs which have silly auth stuff.
Best, imo, would be to add a <groupbox> around remote XUL documents, with a
<caption label="Remote Web Application">, but don't know how easy this would be
to realize.

Or a bar, similar to the new popup notification bar. ("This is a remote web
application, blah blah...")

Both seem to be more elegant than preventing from hiding the location and/or
status bars.
(In reply to comment #29)
> Best, imo, would be to add a <groupbox> around remote XUL documents, with a
> <caption label="Remote Web Application">, but don't know how easy this would be
> to realize.
> 
Yes. A process to diffrentiate between "local chrome" and "remote chrome" and
non-hideable indicators to announce "remote chrome" applications. A frame border
that is yellow and black striped like warning tape coupled with a notifier box
announcing the fact that the striped window is a remote application that may
"look like a web page".

Add to this the ability to locally store a signed copy of the remote
applications chrome file similar to the extension downloads. This way remote
applications can be pulled in once with proper credentials and subsequently use
the downloaded, trusted local copy.

Note that AdBlock and GoogleBar go away on the demo pages (available at
http://www.nd.edu/~jsmith30/xul/test/spoof.html), so it looks like someone with
extensions loaded might catch on to the page being spoofed.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7) Gecko/20040629 Firefox/0.9.1
A fwiw. The spoof doesn't work on the Sky Pilot Classic theme. The bogus
toolbars appear but not the bogus locks in the URLBar nor the statusbarpanel.
That theme uses a different security icon filename and statusbarpanel security
lock placement, which may be the reason for its, apparent, innoculation.
I think that this can be solved the same way Java applets do when they open out
of browser page windows: any non signed XUL jar application or signed jar
without privileges granted, must show a warning attached below the windows
notifying the user that it is a remote not signed application
Here's a (user) suggestion:

By default,when trying to execute a remote XUL app, a dialog should appear
warning the user that is a remote app and letting the user decide if he wants to
execute it anyway. An option to allow all XUL app from that site should be
available in cited dialog.
Also a white list of allowed sites to execute XUL apps, would be available in
Preferences/Security.

This way, it's possible to mantain the same aspect and advanced features of XUL
applications without compromise security.

I hope this can help.

Luiz
I don't know if it's significant or not, but on my version of FireFox
(Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707
Firefox/0.9.2) when I run the spoof demo for .9.0-.9.2 and try to look at the
bookmarks, under 'bookmark this page' the only thing there is an entry labled 
"manBookMarksCmd.label;(_M_ANBOOKMARKSCMD.ACCESSKEY;)"

It seems strange that my real bookmarks weren't loaded, so I thought I'd mention
this in case whatever bug/feature is preventing them from loading might be
exploited to defeat the spoofing itself.
I'm using Firefox 0.8 and I get

<key id="key_newMessage" key="&sendMessage.commandkey;"
command="Browser:NewMessage" modifiers="accel"/>
----------------------------------^

when I run the demo for 0.9-0.9.2.
(In reply to comment #35)
> I don't know if it's significant or not, but on my version of FireFox
> (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707
> Firefox/0.9.2) when I run the spoof demo for .9.0-.9.2 and try to look at the
> bookmarks, under 'bookmark this page' the only thing there is an entry labled 
> "manBookMarksCmd.label;(_M_ANBOOKMARKSCMD.ACCESSKEY;)"
> 
> It seems strange that my real bookmarks weren't loaded, so I thought I'd mention
> this in case whatever bug/feature is preventing them from loading might be
> exploited to defeat the spoofing itself.


I get the exact same thing here , i think this is important to be able to verify
this
(In reply to comment #35)
> I don't know if it's significant or not, but on my version of FireFox
> (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707
> Firefox/0.9.2) when I run the spoof demo for .9.0-.9.2 and try to look at the
> bookmarks, under 'bookmark this page' the only thing there is an entry labled 
> "manBookMarksCmd.label;(_M_ANBOOKMARKSCMD.ACCESSKEY;)"
> 
> It seems strange that my real bookmarks weren't loaded, so I thought I'd mention
> this in case whatever bug/feature is preventing them from loading might be
> exploited to defeat the spoofing itself.


I get the exact same thing here , i think this is important to be able to verify
this
(In reply to comment #38)
> (In reply to comment #35)
> I get the exact same thing here , i think this is important to be able to verify
> this

Sorry!  That's all my fault!  I've been trying to make just the two demos work
for an increasing number of nightly builds, and they're all slightly different.
 I'll try to do some debugging tomorrow.
Sorry for the double post ( something must have gone wrong)
I forgot to mention that i am using -> Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
(In reply to comment #34)
> Here's a (user) suggestion:
> 
> By default,when trying to execute a remote XUL app, a dialog should appear
> warning the user that is a remote app and letting the user decide if he wants to
> execute it anyway.

I think it's a good idea. And/or use a different GUI for all XUL windows.

(In reply to comment #3)
> How about a whitelist for known "good" sites (ex. mozilla.org, mozdev, paypal,
> ebay, amazon, etc etc.), they would be able to use the chrome:// protocol, other
> sites could be added by the user.

Why a whitelist or allow "good" sites ? I don't see why a "good" site would use
chrome://, but we can imagine many "bad" site would try to modify the whitelist.
(In reply to comment #34)
> Here's a (user) suggestion:
> 
> By default,when trying to execute a remote XUL app, a dialog should appear
> warning the user that is a remote app and letting the user decide if he wants to
> execute it anyway. An option to allow all XUL app from that site should be
> available in cited dialog.
> Also a white list of allowed sites to execute XUL apps, would be available in
> Preferences/Security.

Isn't it possible to use some kind of sandbox model as it is used in java? The
idea is to inform the user that a website is XUL enhanced and there might be a
classification of things XUL will address, hiding Menu, statusbar etc.

If that is not possible, sorry XUL, why not deactivate it completely for remote
components, i've learned that mozilla/firefox... needs it for rendering, that is
quite fine, great, but is there a single website that makes use of XUL? Haven't
seen any lately, in the last 10 years or so ;-) </Joke> 

Maybe we should think about some kind of zone model the IE uses: So XUL could be
enabled for local and intranet access and some selected funtions even in the
internet zone. 
(In reply to comment #14)
> Why do we allow content to window.open or otherwise use chrome: URLs?

<img> does not use checkloaduri. iirc that's because that'd break inserting
images in editor... see bug 69070

*** This bug has been marked as a duplicate of 22183 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Flags: blocking-aviary1.0PR+
Flags: blocking-aviary1.0+
You need to log in before you can comment on or make changes to this bug.