Closed Bug 1731028 Opened 3 years ago Closed 3 years ago

iFrame Sandbox Escape

Categories

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

defect

Tracking

()

RESOLVED DUPLICATE of bug 1322925

People

(Reporter: kirtikumar.a.r, Unassigned)

References

()

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36

Steps to reproduce:

  1. Visit exploit
  2. Click the hyperlink
  3. Open Microsoft Edge

Actual results:

It allows executing the script even though we haven't set the attribute of "allow-scripts" and also the iframe is sandboxed

Expected results:

It should give an error saying: Blocked script execution in '<URL>' because the document's frame is sandboxed and the 'allow-scripts' permission is not set in the console

Summary: sandbox → iFrame Sandbox Escape
Group: mobile-core-security → firefox-core-security
Component: Security: Android → Untriaged
Product: Fenix → Firefox

This looks like desktop given edge and calculator links

This looks like desktop given edge and calculator links

The Microsoft-edge will work because it has the same registered handler in Android and Windows. The calculator won't work.

This is a publicly known spec issue and will hopefully be resolved through https://github.com/whatwg/html/issues/2191

There might be an existing or new bug for this then, so I'm closing this one. Thank you for the report, though!

Group: firefox-core-security
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID

This seems to be reasonable. The issue was opened by Jun, MSRC folk before 5yrs. For Bug 1730854, the same should be applicable then as the codebase of the desktop and Android would be the same for this. So, we should be changing the subject line of Bug 1730854 from Sandbox Escape to the: Lack of User permissions/consent while opening any external handlers, yes? As in Bug 1730854, we require two different patches because Firefox on Android behaves differently for the external handlers and opens any applications without asking users if they want to open them or not. Hence, I would be more than happy if we can change the details of the Bug in Bug 1730854 to the lack of security implications/measures. Thanks once again for pointing to the correct Github bug. Cheers!

Flags: needinfo?(jhofmann)

Ok, I hadn't noticed that bug, continuing that discussion there, thanks.

Flags: needinfo?(jhofmann)

Making changes to this bug again after the comment in bug 1730854.

I'd a better look at the URL of the Github provided by @Johann in comment #3.

Why did I re-open this case?
-> The URL provided of Github has a link of the bug 1322925 in that, Jun has provided a PoC when you will have a look at it, you can see the attribute allow-scripts which means that it is allowed to run the scripts as per attb-sandbox. But now, it is again arguable that as per that attribute, it shouldn't be allowed to create a pop-up window.

I have given an explanation in bug 1730854 that when I haven't set the attribute of allow-scripts still it got executed, what was the reason? The answer is that it was an unintended behavior/bug which lead us to render it even though we allowed the sandboxed iframe to render it by using the above-mentioned attribute (i.e. allow-scripts).

What is the expected patch here?
--> As I haven't used the attribute to `allow-scripts, it shouldn't run any script unless I explicitly ask it to do so by using the attribute. Even if I use the attribute, it should block the pop-up windows as per the attb-sandbox

Status: RESOLVED → UNCONFIRMED
Flags: needinfo?(jhofmann)
Resolution: INVALID → ---

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

allow-scripts happens to be what Jun's testcase uses, but it's irrelevant to the problem: he was using the script to make a no-click testcase (which is currently blocked for other reasons). There's no linkage between the scripting permission and whether navigating to an external protocol counts as a "pop-up" or some other reason to block it in a sandbox.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(mail)
You need to log in before you can comment on or make changes to this bug.