Open Bug 1536385 Opened 5 years ago Updated 2 years ago

Popup opened from sandboxed iframe that allows for sandbox escaping does not execute script

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- unaffected
firefox70 --- disabled

People

(Reporter: alex.birsanc, Unassigned, NeedInfo)

References

(Regression,
URL
)

Details

(Keywords: regression, Whiteboard: [reporter-external] [client-bounty-form])

Whenever a sandboxed iframe has the following attributes:

allow-popups allow-popups-to-escape-sandbox

It is possible to execute arbitrary javascript in the context of the iframe's domain, even though the lack of allow-scripts should prevent it.

This can be achieved via a javascript: URI with target=_blank.

Steps to reproduce:

  • Navigate to http://alexbirsan.site/sandbox_a.html
  • Click on the last link on the page
  • An alert box will pop up and display the current document.domain, confirming that javascript code was executed in the context of the iframe's domain

When testing this on other browsers (IE, Edge, Chrome, Opera), all of the links on the page are blocked.

Firefox version: 65.0.2 (64-bit)

Flags: sec-bounty?

It's not clear to me this is a bug based on the spec, though it's very possible I'm misreading the spec. You're creating a popup which is allowed to escape the sandbox, because you've set allow-popups-to-escape-sandbox, and then load a JS URI in that (now unsandboxed) popup.

The same thing would presumably happen if the _blank link pointed to an http/https URL that happened to be same origin, and happened to contain script.

Of course, given all the other browsers (per comment #0, I haven't verified) do something else, perhaps the spec needs changing (or, as noted, I'm misreading it).

Christoph, can you check whether I'm missing something?

Group: firefox-core-security → dom-core-security
Component: Security → DOM: Security
Flags: needinfo?(ckerschb)
Product: Firefox → Core

Chrome blocks the javascript: url inside the original sandbox, THEN opens a popup (or doesn't, if there's nothing to load as in this blocked case). We open the popup, and then since it has escaped the sandbox it's free to run scripts.

But then I can't get the script to run in Nightly. So we fixed this thing that I think isn't a bug?

(the iframe sandbox attribute is normal DOM Core, not DOM: Security (CSP version of sandbox))

Status: UNCONFIRMED → NEW
Component: DOM: Security → DOM: Core & HTML
Ever confirmed: true
Flags: needinfo?(annevk)

My expectation is that the script executes, because the popup (created with target=_blank) is not sandboxed (due to sandbox="allow-popups allow-popups-to-escape-sandbox"). freddyb confirmed that this happens on Fx 65 as reported by comment 0. That the reporter considers this a bug is an error as far as I can tell. HTML states that if sandbox propagates to auxiliary browsing contexts flag is unset, no sandboxing flags get copied to the popup.

Now on Nightly (and maybe earlier?), it seems we have a regression, as it does not execute, and we also create a popup that doesn't really seem to have a document. At least, injecting contents with the console doesn't do anything, when it's initially happened the link cursor remains visible somehow.

Flags: needinfo?(annevk)
Keywords: regression, regressionwindow-wanted
Summary: iframe sandbox bypass via javascript: URI → Popup opened from sandboxed iframe that allows for sandbox escaping does not execute script
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form]

(In reply to Anne (:annevk) from comment #3)

At least, injecting contents with the console doesn't do anything, when it's initially happened the link cursor remains visible somehow.

There's no painting because there's no load after the initial about:blank and there's a [blank] attribute on the browser, but the injecting is working, you can check in the inspector that the DOM is there and being modified. This is the result of attribute handling in tabbrowser, which is potentially something we could fix, but doesn't normally happen unless there are bugs elsewhere (like here).

This does not appear to be a security bug. Arguably our behavior is correct so maybe the spec needs clarifying or a bug lodged against Chrome. Also appears to be an unrelated layout issue in Nightly, but also not a security bug.

Group: dom-core-security

(In reply to Anne (:annevk) from comment #3)

My expectation is that the script executes

I just pulled the latest code from central and there is no popup when executing the STRs from comment 0. Further, there is no indication in the console that we are blocking anything at all. I further tried running a wpt test [1] that includes "allow-scripts allow-popups allow-popups-to-escape-sandbox" which does not work if I remove the 'allow-scripts' flag.

As a web developer I would imagine I have to add 'allow-scripts' so the script executes, but Anne made a good point that no sandbox flags are copied to auxilliary browsing contexts. To me it seems, whatever we do we should extend those wpt tests to definitely cover a matrix of sandbox flags around 'allow-scripts' and 'allow-popups-to-escape-sandbox' to make sure all browser behalf the same.

[1] https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/embedded-content/the-iframe-element/iframe_sandbox_popups_escaping-1.html#7

Flags: needinfo?(ckerschb)
Priority: -- → P3

Hi Alex, any change you could re-upload the test files?
Would want to look into it a bit further and get the regression-range check going.

Thanks!

Flags: needinfo?(alex.birsanc)

We don't have the test cases, but it would be something like:

<iframe sandbox="allow-popups allow-popups-to-escape-sandbox" 
   srcdoc="<a target=_blank href=javascript:alert(document.domain)>popup</a>">
</iframe>

Note that javascript: urls running in the popup might be broken independent of this issue (see bug 1506100), although that predated the Firefox 65 that this was filed against so maybe not.

Flags: sec-bounty? → sec-bounty-

As far as the regression range:

Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox68: --- → unaffected
status-firefox69: --- → unaffected
status-firefox70: --- → affected
status-firefox-esr60: --- → unaffected
status-firefox-esr68: --- → unaffected
Keywords: regressionwindow-wanted

Baku, looks like the noopener changes for _blank targets broke something here per the earlier comments.

Flags: needinfo?(amarchesini)
Regressed by: 1503681

Hsin-Yi, is there anyone else who might work on this regression in 70? I am also not sure the priority is correct here. Thanks!

Flags: needinfo?(htsai)

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

Priority: P3 → P1

(In reply to Cristian Fogel, QA [:cfogel] from comment #10)

As far as the regression range:

Hi Cristian,
I'm confused with the regression window. The suspicious bug 1503681 landed in 65; however, the status of this bug became affected in 70, unaffected in 68 or 69. The information doesn't look consistent. Would you mind confirming again? Thank you.

Flags: needinfo?(htsai) → needinfo?(cristian.fogel)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #14)

(In reply to Cristian Fogel, QA [:cfogel] from comment #10)

As far as the regression range:

Hi Cristian,
I'm confused with the regression window. The suspicious bug 1503681 landed in 65; however, the status of this bug became affected in 70, unaffected in 68 or 69. The information doesn't look consistent. Would you mind confirming again? Thank you.

The implied rel=noopener on _blank links is turned off in late beta and release, see also bug 1546415. This means that this testcase:

<iframe sandbox="allow-popups allow-popups-to-escape-sandbox" 
   srcdoc="<a target=_blank href=javascript:alert(document.domain)>popup</a>">
</iframe>

is "only" broken on nightly and early beta, I expect, so beta will magically be fixed once the EARLY_BETA flag is turned off.

That said, I expect this testcase:

<iframe sandbox="allow-popups allow-popups-to-escape-sandbox" 
   srcdoc="<a target=_blank rel=noopener href=javascript:alert(document.domain)>popup</a>">
</iframe>

will be broken everywhere, and may get us a different regression window.

(In reply to :Gijs (he/him) from comment #15)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #14)

(In reply to Cristian Fogel, QA [:cfogel] from comment #10)

As far as the regression range:

Hi Cristian,
I'm confused with the regression window. The suspicious bug 1503681 landed in 65; however, the status of this bug became affected in 70, unaffected in 68 or 69. The information doesn't look consistent. Would you mind confirming again? Thank you.

The implied rel=noopener on _blank links is turned off in late beta and release, see also bug 1546415. This means that this testcase:

<iframe sandbox="allow-popups allow-popups-to-escape-sandbox" 
   srcdoc="<a target=_blank href=javascript:alert(document.domain)>popup</a>">
</iframe>

is "only" broken on nightly and early beta, I expect, so beta will magically be fixed once the EARLY_BETA flag is turned off.

Thanks Gijs.
I confirmed that if we flip the pref to off, this is fixed.

It looks to me that we don't have plans to flip the pref "dom.targetBlankNoOpener.enabled" to ON by default on LATE_BETA and RELEASE in 70, reading from the status of bug 1522083 and bug 1531289. Maybe moving status-firefox70 to disabled would make more sense? I'm also NI Erica to confirm the plan of pref on.

That said, I expect this testcase:

<iframe sandbox="allow-popups allow-popups-to-escape-sandbox" 
   srcdoc="<a target=_blank rel=noopener href=javascript:alert(document.domain)>popup</a>">
</iframe>

will be broken everywhere, and may get us a different regression window.

I played with several versions. It's broken even back through 64.

Flags: needinfo?(cristian.fogel) → needinfo?(ewright)
Flags: needinfo?(ewright)

Hi Liz, please read comment 16 that I'd like to denominate the tracking-firefox70 flag back to default.
I had a quick chat with Erica that she is busy with Skyline. There hasn't been progress on the blocking bugs in comment 16.

Flags: needinfo?(lhenry)

Firstly, I have to say that I don't really understand which is the bad/unexpected behavior and which is the good/expected one.
I have wrone a local HTML file that contains the code in comment 9 which will work as a test case for the test if this issue:

  • Nightly v71.0a1: Clicking the "popup" link would open another tab with the URL: "javascript:alert(document.domain)";
  • Beta v70.0b6: Clicking the "popup" link would open another tab with the URL: "javascript:alert(document.domain)";
  • Release v69.0: Clicking the "popup" link would open a blank tab with a pop-up that only shows an "OK" button;
  • ESR68 v68.1.0esr: Clicking the "popup" link would open a blank tab with a pop-up that only shows an "OK" button;

Considering the rest of the discussion on the bug, I have assumed that the bad behavior is the one happening in the latest Nightly and Beta builds.

With this informaiton I have attempted to perform a regression with the mozregression tool:
First Bad build: release 70;
Last good build: release 68;
Unfortunately, it appears that the same result (bad) is reproduced throughout the whole set of builds that mozregression throws at me to test. It appears as this cannot be tested by this method. I could finish the process if someone could help determine what's different when running builds from mozregression, in this case.

Thanks.

Please set the flags accordingly if the comment above presents a correct assumption. Furthermore, this has been tested in Windows 10.

Priority: P1 → P2

Given that

<iframe sandbox="allow-popups allow-popups-to-escape-sandbox" 
   srcdoc="<a target=_blank rel=noopener href=javascript:alert(document.domain)>popup</a>">
</iframe>

is generally broken, does this really need to block bug 1522083? As that's the real issue, not that target=_blank implies rel=noopener, right?

Flags: needinfo?(htsai)

(In reply to Anne (:annevk) from comment #20)

Given that

<iframe sandbox="allow-popups allow-popups-to-escape-sandbox" 
   srcdoc="<a target=_blank rel=noopener href=javascript:alert(document.domain)>popup</a>">
</iframe>

is generally broken, does this really need to block bug 1522083? As that's the real issue, not that target=_blank implies rel=noopener, right?

I think you're right!

No longer blocks: 1522083
Flags: needinfo?(htsai)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.