3.28 KB, text/html
3.09 KB, patch
|Details | Diff | Splinter Review|
5.70 KB, patch
|Details | Diff | Splinter Review|
1.69 KB, patch
|Details | Diff | Splinter Review|
13.11 KB, image/png
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.
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.
OS: Windows 2000 → All
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.
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.
we could also block the "chrome" flag for untrusted content, just like we block the "modal" flag....
> 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.
Well, I'm not sure "web page dialog" really applies to something opened by a signed jar with UniversalXPConnect priveleges...
Assignee: general → 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...
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.
(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.
Attachment #149500 - Attachment mime type: text/plain → text/html
> 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.
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.
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.
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.
(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).
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.
> 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?
(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? :-)
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.
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
Assignee: jst → bsmedberg
Status: NEW → ASSIGNED
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 on attachment 149779 [details] [diff] [review] bandaid disables "chrome" flag for untrusted script to non-chrome URI a=chofmann for 1.7
Attachment #149779 - Flags: approval1.7? → approval1.7+
Fixed on trunk, 1.7 branch, aviary1.0 branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Adding Jon Granrose to CC list to help round up QA resources for verification
adding karen to verify on 1.7 branch.
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.
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...
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 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.
Attachment #149779 - Flags: approval1.4.3?
This change is causing problems for which we haven't really sorted out a solution just yet. See for example bug 248004.
Whiteboard: fixed-aviary1.0 → [sg:fix]fixed-aviary1.0
Removing security-sensitive flag for bugs on the known-vulnerabilities list
(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.
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.
Going by the original report/concern about being able to easily create a dialog that looked native... how exactly is this now fixed?
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
Attachment #149779 - Flags: approval1.4.3? → approval1.4.3+
I took the liberty of landing this on 1.4
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)
Note: The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0764 to this issue.
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.
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.
I agree. Take it to bug 248207 which admittedly has a title no one will think to look for.
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)
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.
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.
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.
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.
No unaffected versions listed at SA12188 in August '05.
You need to log in before you can comment on or make changes to this bug.