244965 - Untrusted web content can display content using "chrome" flag in window.open

Status: RESOLVED FIXED

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

Description

[James Ross]

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

An untrusted web page can use the "chrome" flag in window.open to display remote
XUL content without any indication it's not the browser's own UI.

Reproducible: Always
Steps to Reproduce:
1. Load http://silver.warwickcompsoc.co.uk/cps/admin.html
2. Click the link.

Actual Results:  
The remote XUL window opens without any hints it's remote content.

Expected Results:  
A security exception or the 'chrome' flag being ignored.

Comment 1

[Benjamin Smedberg]

This is IMO a serious security flaw. Windows opened with the "chrome" flag get
their own title in the window, which makes spoofing security dialogs or any
other mozilla UI very simple. Marked blocking 1.7 for the moment.

Comment 2

[Benjamin Smedberg]

Attachment: Spoofing exploit: the master-password dialog

Spoofing exmaple: the master-password dialog. It's not a perfect replica,
because it's not really modal and it still has minimize/maximize buttons, but
it's close enough to be scary.

Comment 3

[Johnny Stenback (:jst)]

Attachment: Maybe something along these lines?

This makes XUL windows that don't come from a chrome URI always get a "Web Page
Dialog -- " prefix in the title. How's that sound? That's what IE does with its
modal HTML dialogs, except that IE appends that to the title, so with a long
enough title it can be hidden from the user. This way it's the first thing in
the title, so no matter what title the page specifies, it'll always have this
prefix.

This should probably be a localized string tho (maybe fallback to english
hardcoded text), if others agree that this is a reasonable fix, I can do that
part as well.

Comment 4

[Boris Zbarsky [:bzbarsky]]

we could also block the "chrome" flag for untrusted content, just like we block
the "modal" flag....

Comment 5

[Benjamin Smedberg]

> we could also block the "chrome" flag for untrusted content, just like we block

In 1.5 and before, we did. I don't know whether that changed by accident or on
purpose. As a long-term solution, I think jst's idea is right, though perhaps
more obvious. .NET decorates "untrusted" windows with a little graphical icon or
special colors, if I understand the documentation correctly (haven't tried it
yet).  I don't know what to think for 1.7.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Well, I'm not sure "web page dialog" really applies to something opened by a
signed jar with UniversalXPConnect priveleges...

Comment 7

[Daniel Veditz [:dveditz]]

Instead of purely generic text, how 'bout including the hostname as part of it?
That will help with phishing attacks where the victim isn't surprised by
web-generated content but was fooled into thinking it was some other site.

We should also consider it for browser windows without a location bar, and for
the various "[JavaScript Application]" dialogs we show now.

Assigning to jst to make sure this one has a home. Reassign if you find someone
else to work on it.

Comment 8

[Johnny Stenback (:jst)]

(In reply to comment #7)
> Instead of purely generic text, how 'bout including the hostname as part of it?
> That will help with phishing attacks where the victim isn't surprised by
> web-generated content but was fooled into thinking it was some other site.

That can be relatively easily fooled by something like
"Master-Password----------------------------------.evil.com", that, w/o any
other indication that the dialog isn't native will fool most users into thinking
it's the master password dialog...

Comment 9

[Hixie (not reading bugmail)]

I think we should use the same string here as for the [Javascript Application]
case, for consistency.

Comment 10

[Dan M]

Is there a reason for allowing unprivileged script to open windows as chrome?
Are we ever going to allow remote chrome, anyway? I rather hope not. I'm siding
with Boris

> we could also block the "chrome" flag for untrusted content

though

>In 1.5 and before, we did.

I don't remember that.

There are other issues with windows-as-chrome; see related bug 244766 (odd that
both bugs showed up just this week). Both could be patched separately and I
don't /know/ of any other issues, but why is this even allowed? Feels like an
oversight.

The first thing you discover in speed reading class is that no one reads titles.
No matter what text you put in the title of evil.org's chrome window, some
percentage of users won't notice. Even a small percentage is a big number these
days.

Comment 11

[Dan M]

(PS my second quote in the above comment was Benjamin's, not Boris'.)

Oh. I just thought of another issue. See the demonstration in bug 244766. Notice
how small the window is? Patch #3 wanted.

Comment 12

[Benjamin Smedberg]

> Is there a reason for allowing unprivileged script to open windows as chrome?
> Are we ever going to allow remote chrome, anyway? I rather hope not. I'm siding

Yes, we are, in some decorated form. As part of the XUL toolkit/apprunner, we
want to be able to download a complete XUL app from the network and run it as an
"untrusted" app. But that is future, not now.

Comment 13

[Doron Rosenberg (IBM)]

From a web application perspective: people can disable all the other decorations
using other options in window.open, so making "chrome" not work for untrusted
content shouldn't break anything, especailly if indeed this used to not work
anyways.

Comment 14

[Dan M]

Yeah... we all thought remote XUL was cool for the two days it took before it
struck that gleam in Netscape marketing's eyes. Now it's cool again? Oy. I hope
you guys do this right. Whatever that means.

I still believe that title text is insufficient. It'll help 95% of the time, and
therefore quadruple your support requirements.

I imagine you've all been working on the design and I'm once again late to the
party. But I suggest that windows-as-chrome be openable only from chrome-level
script (either local chrome:// or script in an already-opened as-chrome window),
so that users can't open themselves up to remote chrome from normal web content.
That would neatly make these bugs a non-issue.

>making "chrome" not work for untrusted content shouldn't break anything,
>especially if indeed this used to not work anyways.

Though I'm bound to admit I really don't think this has ever been disallowed.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I agree with danm, in case that wasn't clear -- only script that already has
chrome priveleges should be able to open windows with the "chrome" flag.

If we implement it that way, if we ever decide to give chrome priveleges to
remote content under some constraints things will Just Work as expected.

Comment 16

[Daniel Veditz [:dveditz]]

Re comment 9 -- valid host names can't have spaces so no host name would ever
look quite right. But I wasn't suggesting /just/ the host name as a prefix. The
host name suggestion is is more in response to how unhelpful I find [Javascript
Application] in some alert/confirm dialogs. Better than nothing as it does help
distinguish chrome from content, but doesn't help with one site spoofing another.

But I agree with DanM that a lot of users would overlook the title anyway, we
need something more. If possible, whatever visual distinction we come up with
should apply to location-bar-less HTML windows, which can also be spoofed up to
some extent using images (see the clever phish analysed at
http://antiphishing.org/news/03-31-04_Alert-FakeAddressBar.html)

Comment 17

[Johnny Stenback (:jst)]

(In reply to comment #15)
> I agree with danm, in case that wasn't clear -- only script that already has
> chrome priveleges should be able to open windows with the "chrome" flag.
> 
> If we implement it that way, if we ever decide to give chrome priveleges to
> remote content under some constraints things will Just Work as expected.

But the "chrome" flag doesn't actually give the page chrome priveleges (or did I
miss something obvious here?), it only ends up creating a chrome window, which
isn't all that different from a normal window. You only get chrome privs if
you're loaded from a chrome:// URL (though there could be code somewhere that
checks the type of the docshell, and makes assumptions based on that).

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #16)
>If possible, whatever visual distinction we come up with
> should apply to location-bar-less HTML windows, 

could we always show the status bar, with a message like "JavaScript
Application" always visible in it, and not allowing the window to be sized in
such a way that this text is invisible (outside the screen)?

Comment 19

[Johnny Stenback (:jst)]

Attachment: Use ScriptDlgTitle, if available.

This is pretty much the same thing as the earlier patch, except that it uses
the same dialog prefix that alert() n' friends use.

Whether or not this is enough to fix thsi bug I think we should land this
change since we'll need it for modal HTML dialogs (which we *are* going to
support, see bug 194404). We might need more, but this is IMO a step in the
right direction.

Comment 20

[Boris Zbarsky [:bzbarsky]]

> though there could be code somewhere that checks the type of the docshell

I'm pretty sure we do have code like that; what it decides based on the type is
a separate issue.... (that should be investigated in any case, apparently).

Perhaps if the window flags were somewhat documented we'd have a better basis
for making this sort of decision. :(

Let me approach this from a different angle.  What does the "chrome" flag do? 
If it makes windows look like they are just part of Mozilla itself, under what
circumstances would it be useful to use it from a web author or XUL application
author perspective?  If so, can we allow it only in those cases?

If this flag does something else, then what does it do?

Comment 21

[Johnny Stenback (:jst)]

(In reply to comment #20)
> Perhaps if the window flags were somewhat documented we'd have a better basis
> for making this sort of decision. :(
> 
> Let me approach this from a different angle.  What does the "chrome" flag do? 
> If it makes windows look like they are just part of Mozilla itself, under what
> circumstances would it be useful to use it from a web author or XUL application
> author perspective?  If so, can we allow it only in those cases?
> 
> If this flag does something else, then what does it do?

Danm, got any words of wisdom to share with us here? :-)

Comment 22

[Dan M]

Setting the chrome flag promotes the loaded content into being the window's
chrome. Put another way, it fails to wrap the standard browser chrome around the
contents loaded from the URL. Put another way, it allows you to define how the
window looks on an application level. So
> If it makes windows look like they are just part of Mozilla itself
yeah, basically.

Though not necessarily like Mozilla. It's probably important for remote XUL,
which I imagine to be a GRE toolkit capability supporting network applications.
That's not a secret, is it? If it is, this bug will have to remain security
sensitive for a while longer :) And no, no one told me that. It's just an
(educated) guess.

>you're loaded from a chrome:// URL (though there could be code somewhere that
>checks the type of the docshell, and makes assumptions based on that).

There is indeed. See the oft-mentioned, though only by me, bug 244766. Waugh! I
demand that my other bug get some attention! I've done a cursory scan of the
code and I could find no additional examples, but this
>Oh. I just thought of another issue. See the demonstration in bug 244766.
>Notice how small the window is?
is probably another one. I didn't find it in my cursory scan, either.

As-chrome windows don't have chrome:// privileges, so their potential damage is
very limited. But I can think of at least three source snippets that need to be
tightened up (all mentioned already in this bug). The most worrisome aspect I
know of is this bug itself: as-chrome is an awesome, air-horn-blasting phishing
vulnerability and for that reason alone I don't understand the resistance to
slapping some privilege requirements on it. I think it could be done without
harming remote XUL.

Comment 23

[Benjamin Smedberg]

Yes, I think the immediate solution is to allow only windows opened *by* trusted
script *or to* a trusted page should be allowed to use the "chrome" flag. I can
make a patch Tuesday if nobody beats me to it. It looks like a fairly simple
hack in windowwatcher::OpenWindowJS

Comment 24

[Benjamin Smedberg]

Attachment: bandaid disables "chrome" flag for untrusted script to non-chrome URI

Comment 25

[Johnny Stenback (:jst)]

Comment on attachment 149779 [details] [diff] [review]
bandaid disables "chrome" flag for untrusted script to non-chrome URI

sr=jst, but I'd like danm's blessing on this too...

Comment 26

[chris hofmann]

Comment on attachment 149779 [details] [diff] [review]
bandaid disables "chrome" flag for untrusted script to non-chrome URI

a=chofmann for 1.7

Comment 27

[Benjamin Smedberg]

Fixed on trunk, 1.7 branch, aviary1.0 branch.

Comment 28

[Daniel Veditz [:dveditz]]

Adding Jon Granrose to CC list to help round up QA resources for verification

Comment 29

[Jon Granrose]

adding karen to verify on 1.7 branch.

Comment 30

[Dan M]

Hello, can we please stop adding comments when simply cc:ing people? Basic
bugzilla etiquette and all that? I'll refrain from repeating this complaint in
every bug this has been done to lately, but you know I want to do that.

Comment 31

[Karen Huang]

Verified as fix on latest 1.7 branch 06-18 build.
Changing keywords from fixed1.7 to verified1.7.
Leave this bug status "as is" until this bug be verified on trunk again...

Comment 32

[Dan M]

Authors of remote XUL have begun to notice. See bug 248004. Now is the time for
remorse, if you're so inclined.

I have a little. I've just told people they'll need to start asking for
UniversalBrowserWrite permission to keep their svelte remote XUL windows. That
of course grants even more privileges. Suddenly it occurs to me that the
normally scary UniversalBrowserWrite Permission Dialog may become so widely used
that users become inured to it. That would be even worse than the situation
before this bug.

Comment 33

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 149779 [details] [diff] [review]
bandaid disables "chrome" flag for untrusted script to non-chrome URI

Unsure if we want this for 1.4.3 because of the potential pitfalls (see omment
#32 from danm), but its definitely worth consideration because of the nature of
this bug.

Comment 34

[Dan M]

This change is causing problems for which we haven't really sorted out a
solution just yet. See for example bug 248004.

Comment 35

[Daniel Veditz [:dveditz]]

Removing security-sensitive flag for bugs on the known-vulnerabilities list

Comment 36

[Christopher Aillon (sabbatical, not receiving bugmail)]

(In reply to comment #32)
> I have a little. I've just told people they'll need to start asking for
> UniversalBrowserWrite permission to keep their svelte remote XUL windows. That
> of course grants even more privileges. Suddenly it occurs to me that the
> normally scary UniversalBrowserWrite Permission Dialog may become so widely used
> that users become inured to it. That would be even worse than the situation
> before this bug.

Dan, don't you have to have a pref set
(signed.applets.codebase_principal_support) before you will even be asked about
this?  I don't think a default profile will even prompt the user with this
dialog.  In which case, the situation won't really be worse unless the user
knows enough to enable that.  I'd hope that in that case, they would have some
knowledge of what this does; but perhaps that is too optimistic.

Comment 37

[Dan M]

I'd forgotten that at the time. Yes, UBW is useless unless the user happens to
have flipped that pref. My favorite suggestion for a fix is a toned-down version
of UBW outlined in bug 248207. But that doesn't seem to be a popular suggestion.
And I think the approach in bug 248004 is a travesty but again, seemingly
unpopular opinion.

Comment 38

[WD]

Attachment: Screenshots compared - pre and post patch, plus the real one

Going by the original report/concern about being able to easily create a dialog
that looked native...	how exactly is this now fixed?

Comment 39

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 149779 [details] [diff] [review]
bandaid disables "chrome" flag for untrusted script to non-chrome URI

While it sucks that things are broken because of this, the popup window issue,
and potential for abuse are too great to not take this IMO.   It would be very
great to get a fix for the regression (bug 248004), but the lack of dupes to
that bug in over a month seem to imply that not a whole lot of people are hit
by the regression, which is one more reason I think this should make 1.4.

a=blizzard for 1.4.3

Comment 40

[Christopher Aillon (sabbatical, not receiving bugmail)]

I took the liberty of landing this on 1.4

Comment 41

[nrlz]

If all that the chrome flag does is make windows look like they are part of
Mozilla, well isn't that already possible now? Webpages can already open a
window with no toolbars or statusbar. They can hide the minimize and maximize
buttons with 'dialog' and 'dependent' in windows.open(). And they can push out
the '- Mozilla' text in the titlebar with a series of ' 's. Firefox also
goes a step further by not drawing a border around the content area which makes
the web content flow right into the window. (like with #252389)

Comment 42

[Mark Cox]

Note: The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0764 to this issue.

Comment 43

[Duong Thanh An]

What do you think about allowing remote XUL chrom window which is opened by
"mozilla -chrome http://...." to open a child chrome window without any
restrictions?

This should help keeping the current implementation of remote XUL applications
unchaged.

Comment 44

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

What we're really in dire need of is some sort of UniversalWebApp privilege.
This would allow things like window-as-chrome and statusbar-less windows as well
as hiding context menues, opening popups and all other sorts of things that
web-applications need to do.

In my mind there is simply no way to cram untrusted webpages and fullfeatures
neatlooking webapps within the same security boundrys. Pages could then use
signed jars or whatever mechanism we use now to obtain this privilege.

If we would combine such a feature with some sort of security-zone ability we
could let it-departments preconfigure mozilla to allow all intranet sites to
have UniversalWebApp privileges.

Once that's done we could really tighten security for untrusted webpages at the
same time as giving lots of wanted powers to webapp developers.

Comment 45

[Dan M]

I agree. Take it to bug 248207 which admittedly has a title no one will think to
look for.

Comment 46

[Hixie (not reading bugmail)]

Two things to note:

 1. WHATWG has been tossing around that idea for a few weeks now.

 2. The idea of having separate zones is one of the things we have repeatedly 
    told reporters is the cause of many bugs in IE.

Personally I would rather have an info bar in every new popup that tried to hide 
chrome, and have that info bar expose three options:

    Never trust this site (always show address bar for its popups)
    Trust this site (never show address bar for its popups)
    Close info bar (doesn't reappear on this site for this session, but leaves 
    address bar as is)

Comment 47

[Daniel Veditz [:dveditz]]

You really only need the close button and a trust button, the "never trust"
button just takes up space: once trusted you couldn't use it to get the site
back, that UI would have to be elsewhere.

Comment 48

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I defenetly agree that zones are scary, but I do really think we need to limit
what we allow untrusted content to do, while preserving (and in some cases
increasing) what trusted content can do. But we defenetly need to make it secure.

Comment 49

[Nicholas Allen]

That info bar sounds exactly like the new bar in the XP SP2 version of IE.  I
believe they allow two choices: closing the bar and trusting the site for this
session.  There's no permanent deny and permanent trust requires doing more work
to get things signed.

Comment 50

[Juha-Matti Laurio]

This was assigned to SA12188; Mozilla / Mozilla Firefox User Interface Spoofing
Vulnerability
http://secunia.com/advisories/12188/

Solution Status is not 'Patched' in Mozilla Suite yet.

http://secunia.com/product/3691/ (Product Search for Mozilla 1.7.x) returns
SA12188 as 'Partial Fix' on 5th March, 2005.

Comment 51

[Juha-Matti Laurio]

No unaffected versions listed at SA12188 in August '05.