578759 - No clickjacking protection possible on 3.6 due to design mode, port #519928 back

Status: RESOLVED WONTFIX

(Core :: DOM: Editor, defect)

Description

[Hans Schmucker]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; Win64; x64; en-US; rv:2.0b2pre) Gecko/20100713 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6

Due to Bug 519928 (and missing CSP support), there is currently no way to protect any non-Javascript dependent page from Clickjacking.

While this may seem more or less theoretical, the issue is actually quite real for GMail's HTML and Mobile views, which are currently entirely unprotected (in contrast to the Ajax version, which hides itself if Javascript is disabled) since there's no way to escape an iframe if Javascript has been disabled via design mode and no way for the server to know that the document is loaded in a Javascript-blocking context.

Porting back the patch from bug #519928 would fix this issue and make it at least possible to design secure sites without hassling the user. The alternative as it stands now is to serve a sort of captcha (not actually a captcha, but something that places a "continue" button at a random position) to Firefox 3.6 users.

I know that using framebusting isn't exactly the best mechanism to start with, but as far as I know this is currently the only method available in 3.6

Maybe (hopefully) I'm missing something and there is a way to protect Firefox 3.6 users some other way.



Reproducible: Always

Steps to Reproduce:
1. Open the testcase from bug #519928 in 3.66
2. Observe that Javascript is disabled

Comment 1

[(no longer active)]

I don't think that the patch landed in bug 519928 is safe for us to take on branch, especially since it includes functional changes, which is likely to break some editor widgets.  I may need to consider this a bit more, but the downside is that as far as I know, there is no workaround for this problem available. :(

Comment 2

[Hans Schmucker]

Thanks Ehsan,

the problem is I'm running out of ideas for alternatives. We could port the CSP or Microsoft's subset of it back to 3.6, but these patches are a good deal more complex and difficult to port back.

The patch described in #519928 on the other hand is relatively simple and the basic principle is already relatively well-tested since Chrome had this behavior from the start.

Comment 3

[(no longer active)]

(In reply to comment #2)
> Thanks Ehsan,
> 
> the problem is I'm running out of ideas for alternatives. We could port the CSP
> or Microsoft's subset of it back to 3.6, but these patches are a good deal more
> complex and difficult to port back.

Agreed.

> The patch described in #519928 on the other hand is relatively simple and the
> basic principle is already relatively well-tested since Chrome had this
> behavior from the start.

Well, honestly, that patch is not that simple, especially since it touches a very crucial part of code which is responsible for deciding whether JavaScript can run in the context of every document.

And the compatibility problem is that web applications have lots of browser-specific code to handle HTML editing quirks of each browser, and while Chrome might have a similar behavior, some web apps can be relying on the existing behavior for Firefox specifically...

Also CCing Smaug for comments.

Comment 5

[Hans Schmucker]

The way carrying the least amount of risk (but probably much more work intensive) would be a proprietary header, like -moz-no-embedd (only on branch, since it would be replaced by CSP in 4.0). However I still think porting #519928 would make more sense since we've essentially already broken security on many pages that were once secure and still are in other browsers. 519928 would restore that security.

Comment 6

[Hans Schmucker]

BTW, I meant "relatively simple" in the sense that the patch doesn't touch too many components, not as in "easy to write".

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to comment #5)
> The way carrying the least amount of risk (but probably much more work
> intensive) would be a proprietary header, like -moz-no-embedd (only on branch,
> since it would be replaced by CSP in 4.0).

That's silly, it would be equivalent to and the same amount of work as X-Frame-Options without any compatibility and thus very unlikely to be used. Especially since it's a dead-end replaced by the real thing in Firefox 4. I don't see any reason we can't just do bug 475530 (maybe without the UI to avoid giving localizers fits, but that's OK for the stable branches because Safari gets by without UI for blocked frames).

I'm not sure why this bug needs to be hidden as security sensitive, it's functionally a dupe of bug 519928 and the specific attacks against mobile/html GMail were noted in Paul Stone's BlackHat Europe talk.

Comment 8

[Hans Schmucker]

Daniel, I hid it because I did want to discuss this specifically regarding real-world cases. If you want to unhide it, please delete the attachment first.

About the extra header: i agree, it's silly and it was meant as a response to changing-behavior-on-stable-branch-too-risky.

Comment 9

[(no longer active)]

Dan, what do you think about taking bug 519928 on branches?

Comment 10

[Hans Schmucker]

This isn't directly related, but it may make this whole endeavor unfeasible anyway: Is remote XUL allowed to use the XUL browser element the same way as chrome, i.e. creating a separate context that scripts can't escape from (I can't test right now, have to leave in 10 minutes)? Remote XUL was scheduled for removal in 4.0 anyway (although I'll be damned if I can find the tracking bug for it), but that would definitely be a a change that's too big for 3.6 and would make effective clickjacking protection by making sure framebusting works impossible anyway. Then the header approach might actually be the only one possible.

Comment 11

[Hans Schmucker]

OK, got a few more minutes: I couldn't get the xul:browser element to behave this way when used remotely, so I think the initial assessment still stands.

Comment 12

[(no longer active)]

Jonas probably knows the answer to comment 10.

Comment 13

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

I really can't recommend using remote XUL for basically anything. First of all, remote XUL is a mozilla specific technology, and so it won't work in other browsers. Second, we are still planning on removing it for Firefox 4.

If there are features that work in other browsers, but for whatever reason doesn't work in firefox, please do file a bug on the specific feature.

Comment 14

[Jesse Ruderman]

Backporting X-Frame-Options seems like the sanest solution to me.

Comment 15

[Hans Schmucker]

Jonas, I meant remote XUL as an attack vector. I doubt these guys care if it's proprietary ;)

Jesse, that would be fine by me, I just thought that this might actually have a bigger impact on compatibility than changing design mode behavior.

Comment 16

[Hans Schmucker]

Could somebody please delete the attachment since this bug is now public. I posted it to illustrate how dangerous this is, not as a tutorial for hackers ;)

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Jesse made the attachment private. It's safe.

Comment 18

[Hans Schmucker]

Google has by now disabled the password manager, so this exploit doesn't work anymore anyway... wish that were true for Amazon and the rest.

Comment 19

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

Because of status2.0: unaffected and 3.6.x not being supported anymore, this is WONTFIX.
Please open a new bug if there is still something to fix.