403590 - Mixed content detection fails to account for cross-frame scripting

Status: RESOLVED WONTFIX

(Core :: DOM: Security, defect, P3)

Description

[Adam Barth]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

When an https page embeds an http script, the browser detects that the current page has been contaminated with insecure script and can be controlled by an active attacker but fails to detect that other pages in the same origin have also been contaminated.  An active network attacker who as compromised the first page can control all the other pages in the origin as well.

Additionally, this attack can be carried out *silently* if the attacker's http page embeds a frame to the https page that embeds an insecure script.

Reproducible: Always

Steps to Reproduce:
 1) Navigate to <https://www.stanford.edu/~collinj/research/frame/first.html>.
 2) Click "Simple attack."
 3) Notice the popup embedded an http script and has a mixed content warning.
 4) Return to the original tab.
 5) Notice it has been haxored by the popup but retains an unbroken lock icon (or a happy Larry).

The "Stealthy attack" link demonstrates the silent version of the attack.
Actual Results:  
The browser fails to notice that the entire origin is contaminated with insecure content.

Expected Results:  
The browser should notice that the entire origin is contaminated with insecure content.

Comment 1

[Collin Jackson]

Attachment: SafeLock browser extension version 0.1

One approach for fixing this bug is to remember when an https origin is contaminated by insecure content and show the security indicator as degraded (e.g. put a slash over the lock) at that origin for the remainder of the browsing session. Here is a browser extension that demonstrates this approach.

This approach would also fix bug 358438.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

I think this is probably a duplicate of bug 308496 (sorry for not having mentioned that bug when you initially reported this to security@).

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Hrm, not duplicates, I guess, since that one's about XMLHTTPRequest specifically, although they both involve DOM code failing to notify PSM code of downgraded security.

Comment 4

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

Dan, Brandon: Do we think there is a reasonable chance that we can simply disallow https -> http loading of scripts?

If so, we should do it for beta1 to test how many sites break over such a policy.

Comment 5

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

Marking P1 as we'd definitely want to make such a change for beta1.

Comment 6

[Johnathan Nightingale [:johnath]]

(In reply to comment #4)
> Dan, Brandon: Do we think there is a reasonable chance that we can simply
> disallow https -> http loading of scripts?
> 
> If so, we should do it for beta1 to test how many sites break over such a
> policy.

Without having done meaningful data collection, my gut feeling is that this would break a very large number of sites.  I think of people js including libraries like jquery over http, analytics scripts (I know google tries to be smart about serving from https for https pages, but I doubt everyone is so astute), and the like.

Even a site like BritishAirways, which went through the trouble of getting an EV cert, regularly seems to lose its "green bar" status because some new web site revision includes an http js include.  It's good that we detect that and break the security indicators, I think we should fix the cross-frame issue here too, but I think blocking those loads wholesale would be a Big Deal.

Comment 7

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

Apparently IE already blocks these types of thing by default and require user interaction to get the resource to load.

Ideally we could do the same, but I wonder if we could get away with not allowing it at all...

Comment 8

[Adam Barth]

IE7 shows the user a modal dialog for mixed content, which almost guarantees that the user will agree to load the content.  Maybe an infobar is a better approach?  I think that's the approach used in Chrome.

Comment 9

[Johnathan Nightingale [:johnath]]

Yeah, and re-reading my previous comment, I see that it could be taken as more conservative than I intend it to be.  I'm all for blocking insecure content loads in secure pages by default, if there is a way that a user can get involved to override our attempts to keep them safe.  I thought earlier comments were proposing to drop them silently, beneath the user layer, which I think would break a bunch of sites in ways that would inspire... distaste, I imagine.

Not to tangent off into UI land, but I agree absolutely that this should be a non-modal interaction, akin to blocking a popup.  "This site does an annoying thing that we stopped, but this is a case where you may know better than us" being, I think, the guiding principle.

So Jonas, you wanna take a crack at bug 62178, the everlasting bug that prevents this UI from existing?  :)  Kai Engert and I would buy you a bottle of scotch apiece.

Comment 10

[Bobby Holley (:bholley)]

Hey Tanvi,

We're not sure if this bug is still an issue. Given your work with the mixed content stuff, can you determine what needs to be done next here and resolve if need be?

Comment 11

[Tanvi Vyas[:tanvi]]

I am working towards blocking mixed active content by default.  You can see the master bug 815321 which has a bunch of dependency bugs.  I'm adding this bug to the dependency list.

We were actually talking about this issue on irc recently.  There is no good way to do this with the current implementation of nsMixedContentBlocker.  We set the security state per page, not per principal.  The flags associated with mixed content are set on the root document of a window.

There are discussions about moving these flags to the principal instead to solve the attack described here.  However, that may cause other issues...

Assume https://exampleA.com embeds https://exampleB.com.  https://exampleA.com has mixed script but https://exampleB.com does not.  If we enable mixed script on the page, do we mark both principals as compromised?  What about in the reverse situation?  If https://exampleA.com doesn't have mixed script but https://exampleB.com does, then is there even an option to enable mixed script on the window (this is up for debate in https://bugzilla.mozilla.org/show_bug.cgi?id=826599)

We have to work through what we want the expected behavior to be and then we have to see if using the principal can satisfy that behavior.  Another option is using the DocShellTreeOwner for the multiple flags and then setting a tainted flag on tainted principals that is checked when the security state is set in onSecurityChange.

This bug can probably be opened up, but I leave it up to the sec-assurance team to decide that.

Comment 12

[Devdatta Akhawe [:devd]]

> Assume https://exampleA.com embeds https://exampleB.com. 
> https://exampleA.com has mixed script but https://exampleB.com does not.  If
> we enable mixed script on the page, do we mark both principals as

if A is the top level frame, that is what the user sees to make a decision on mixed script. Enabling mixed content on A should not allow mixed content on B. Thus, ideally we would not allow mixed content on B. If compat considerations don't allow this, then we should go ahead and enable mixed content for both (including a change to the UI so that both A and B are listed in the mixed content doorhanger ), but we should be clear that we are doing this only for compat reasons and that it is still a security issue. 

Now whether principal would be sufficient is another question. The fact that CSP is attached to principals makes me think principals are also per-document. This might not be true: do the popup and the main window (see poc) share the same principal ?

Comment 13

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Adam Barth from comment #0)
> When an https page embeds an http script, the browser detects that the
> current page has been contaminated with insecure script and can be
> controlled by an active attacker but fails to detect that other pages in the
> same origin have also been contaminated.  An active network attacker who as
> compromised the first page can control all the other pages in the origin as
> well.

Using 
https://ie.microsoft.com/testdrive/browser/mixedcontent/assets/woodgrove.htm
it seems like Chrome has similar behavior to what we are planning for our implementation: we consider the page to be tainted but not the entire origin.

It isn't clear to me that the origin is the right scope for tainting when we consider various cross-origin communication paths that mixed script could also abuse to potentially taint other origins. Additionally, it seems risky for our first implementation of mixed content blocking to add this behavior, because it is confusing as to why one tab affects another tab. If we want to go down that route then we would have to reconsider the cross-tab and persistent effects that every security feature has. For example, should we avoid caching pages that load mixed content and/or pages that were loaded on connections with overridden certificate errors? Probably we eventually should. But, for now, and until we can convince more websites (including mozilla.org in particular) to stop using mixed content, I am content with keeping the scope of what we considered infected at "one page load" + session restore for that page.

> Additionally, this attack can be carried out *silently* if the attacker's
> http page embeds a frame to the https page that embeds an insecure script.

We should verify (and write a test) that Tanvi's changes to the UI cause the UI to switch to the mixed content version.

> We were actually talking about this issue on irc recently.  There is no good
> way to do this with the current implementation of nsMixedContentBlocker.  We
> set the security state per page, not per principal.  The flags associated
> with mixed content are set on the root document of a window.
> 
> There are discussions about moving these flags to the principal instead to
> solve the attack described here.

According to devd, moving the flags to the principal would still make the flags per-pageload.

> Assume https://exampleA.com embeds https://exampleB.com. 
> https://exampleA.com has mixed script but https://exampleB.com does not.  If
> we enable mixed script on the page, do we mark both principals as
> compromised?

For the initial work, we only need to set the flags at the root level, because they are only used for per-tab state that only affects the UI. If we fix *this* bug then we'll need to revisit it, but I suggest we punt on it for the first iteration.

> What about in the reverse situation?  If https://exampleA.com
> doesn't have mixed script but https://exampleB.com does, then is there even
> an option to enable mixed script on the window (this is up for debate in
> https://bugzilla.mozilla.org/show_bug.cgi?id=826599)

I agree with bsmith on that one.

> We have to work through what we want the expected behavior to be and then we
> have to see if using the principal can satisfy that behavior.  Another
> option is using the DocShellTreeOwner for the multiple flags and then
> setting a tainted flag on tainted principals that is checked when the
> security state is set in onSecurityChange.

Setting on the principal or DocShellTreeOwner should have the same effect on non-e10s Firefox. But, for e10s-based Firefox, setting it on the principal seems like it will work out better, because then we can implement mixed content blocking purely in the parent process.

> This bug can probably be opened up, but I leave it up to the sec-assurance
> team to decide that.

I also agree that this bug can be opened up.

Comment 14

[Daniel Veditz [:dveditz]]

The Mixed Content Blocker has long since prevented loading scripts and other insecure content; currently only media resources can be loaded insecurely and should not pose a large risk of infecting more of the site's content. Level 2 of the Mixed Content Blocker proposes blocking all content, which I believe Chrome is currently shipping. We also have "HTTPS-only mode" (not on by default) the further prevents this problem.

As we pursue a strategy of stricter blocking it does not make sense at this time to invest in the "spread the taint" approach proposed here.