1730854 - HTML5 Sandbox Escape - **iframe** Sandbox Attribute

Status: RESOLVED DUPLICATE of bug 1322925

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

Description

[Kirtikumar Anandrao Ramchandani]

Attachment: sandboxed.PNG

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

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
Please take a look at the attached image for the expected behavior.

Comment 1

[Kirtikumar Anandrao Ramchandani]

For a better experience, try it on "Brave browser--> New private window with Tor" or Open it on the Internet Explorer as it was patched in it. In both of those browsers. it will block. A video demonstration trying the exploit in the Brave with TOR can be found here.

It was tested on Firefox Android and Windows.

Comment 2

[Kirtikumar Anandrao Ramchandani]

Sorry, forgot to add. I am talking about this Sandbox. This isn't a reference to the Sandbox which is used with the "Code execution exploits".

Comment 3

[Daniel Veditz [:dveditz]]

Is the HTML spec clear that external protocol handlers are supposed to be blocked by the sandbox? Do we already have an issue on this?

Comment 4

[Daniel Veditz [:dveditz]]

We patched the moral equivalent of this using android intents in bug 1584582

Comment 5

[Kirtikumar Anandrao Ramchandani]

In Firefox Android, this vulnerability is present too. I'd to file a new bug for fenix but haven't done yet.

Comment 6

[Kirtikumar Anandrao Ramchandani]

Bug 1731028 is the same as this case, that case is in Android. Filed a new case as the Fenix cases are tracked separately.

Comment 7

[Anne (:annevk)]

I cannot reproduce this on macOS, but I suppose the issue is that you can open Microsoft Edge through a link with a custom URL scheme, even when the link is in a sandboxed document. This is a known problem that is discussed in https://github.com/whatwg/html/issues/2191.

This seems like a duplicate of bug 1322925 therefore? However, I do think we should tackle this so that doesn't seem like the way to go. It also seems from the discussion in bug 1731028 that the user isn't asked whether opening this link is okay?

Comment 8

[Kirtikumar Anandrao Ramchandani]

I cannot reproduce this on macOS

I haven't tested on macOS. So, I can't answer it. But to check this case, you have to use a URI which has a registered handler and in Windows like in this test case, we'd microsoft-edge: for the Microsoft Edge and Calculator: for the Calculator. Similarly, you can try to create a PoC with those register handlers of macOS and try with it?

This seems like a duplicate of bug 1322925 therefore?

At least it doesn't seem to be a duplicate of that case due to the reason that Jun has used the allow-scripts when you set the sandbox to allow-scripts it will obviously allow you to render it but here, the case is that when I haven't set the permission of allow-scripts so, it shouldn't allow me to render/open script. For better clarification, I attached a screenshot in the initial report, please refer to it. That's what expected behavior is.

Expected behavior: When I haven't set the permission to allow the script to be rendered in the sandbox still it got rendered which is misbehavior and/or unexpected.

Poc in bug 1322925 is below:
<iframe src="/proto.proto.html" sandbox="allow-scripts"></iframe>

In the poc, you can see that the sandbox is allowed to render the scripts by using the attribute of allow-scripts. So, I don't think the case is same. In my case, I haven't set the attribute of allow-scripts so, it shouldn't do that. I hope this was helpful? If not, I should try for a patch directly maybe.

It also seems from the discussion in bug 1731028 that the user isn't asked whether opening this link is okay?

Correct. As per the discussion in bug 1731028, this case requires two patches, describing below:

1. When any external protocol is opened, Firefox (desktop) will ask you if you want to open the application this prevents attackers to run the malicious scripts in the background while the user closes the application which was opened by him/her. Furthermore, the application can open any URL for example the exploit scenario in Android will be like this:
   data:text/html:<a href="microsoft-edge:any porn site or anything which is illegal">click me</a>

Assume an attacker uses a URL that is illegal in your area and it directly opens in the user's browser without asking him if he wants to open it or not. This will cause problems for the user. Here, we should ask a user if he/she wants to navigate to that application or not. Note: there is a list of URLs banned by telecoms that can be used in such an attack scenario.

2. The second case which requires a patch is the same as Firefox (desktop) which is about blocking the external handlers from being rendered when the iframe is sandboxed and it doesn't have a allow-scripts. So, we should be patching both the cases taking this bug into consideration. I hope this helps?

Thanks once again. Cheers! :)

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to Kirtikumar Anandrao Ramchandani from comment #5)

In Firefox Android, this vulnerability is present too. I'd to file a new bug for fenix but haven't done yet.

Yes, of course: this is a "gecko" bug in shared code. I didn't mean Android did not suffer from this specific bug, but that there was an additional bug on Android that was basically the same logical issue ("does launching an external program count as a pop-up?") using a different mechanism. The "external protocol" version of this has been known and argued about for a while.

Comment 10

[Kirtikumar Anandrao Ramchandani]

(In reply to Daniel Veditz [:dveditz] from comment #9)

Yes, of course: this is a "gecko" bug in shared code. I didn't mean Android did not suffer from this specific bug, but that there was an additional bug on Android that was basically the same logical issue ("does launching an external program count as a pop-up?") using a different mechanism. The "external protocol" version of this has been known and argued about for a while.

Exactly. I have created a new bug where we should land the same patch as the desktop for URIs and also add one extra patch as mentioned for launching another application which is followed on all the Firefox variants of Desktop.

Comment 11

[Daniel Veditz [:dveditz]]

At least it doesn't seem to be a duplicate of that case due to the reason that Jun has used the allow-scripts when you set the sandbox to allow-scripts it will obviously allow you to render it but here, the case is that when I haven't set the permission of allow-scripts so, it shouldn't allow me to render/open script.

The allow-scripts in Jun's earlier bug was irrelevant to the underlying issue, only used for convenience because of the way he wrote the testcase. He used scripts to trigger the navigation, whereas you used a manual click. Opening an external protocol is not "running scripts", at least not running web scripts in that web site's context which is the point of the sandbox. "scripty things" might happen though. It's also not technically a "pop-up" in the web sense, but it does cause the experience of "things open up unexpectedly". It feels wrong, which is why there's an HTML issue about it. The question to be resolved is trying to figure out whether it fits under one of the current categories of wrong or if it needs its own enabling keyword, or whether we should just block it full-stop.

You could write a cross-platform version of this test with something like zoommtg:// or skype:// or slack:// or something else that's got clients on multiple platforms.

Assume an attacker uses a URL that is illegal in your area and it directly opens in the user's browser without asking him if he wants to open it or not. This will cause problems for the user. Here, we should ask a user if he/she wants to navigate to that application or not.

This is not the point of a sandboxed iframe. The above can already happen through malvertising or any number of ways that are not sandboxed. The sandbox is to protect the hosting web site from being harmed in case they are framing untrusted 3rd party content. It not at all clear how these protocol handlers harm the hosting web site. They certainly can annoy users, and possibly be a vector for attack if there's a known bug in that protocol handler (or even a privacy leak even if there is not a "bug" in the handler).

Comment 12

[Daniel Veditz [:dveditz]]

(In reply to Kirtikumar Anandrao Ramchandani from comment #10)

Exactly. I have created a new bug where we should land the same patch as the desktop for URIs and also add one extra patch as mentioned

Changes to "Gecko" generally don't need special Android bugs -- they will get those changes. If the change involves user-interface, such as a new prompt, then that's often needs a separate bug. It looks like bug 1731028 was duped to the old bug for the Gecko part, but the UI ("extra patch") was ignored.

Comment 13

[Daniel Veditz [:dveditz]]

Your comment 4 was not clear, sounds like you said this bug should be changed to be about the prompt, but Desktop already has a prompt (that users can turn off). I think it would be better to leave bug 1731028 alone and file a new bug on just that aspect. Trying to turn that other bug into just that bit will be far too confusing -- people would have to ignore everything 10 comments in.

We may already have a Fenix bug on the prompting issue

Comment 14

[Kirtikumar Anandrao Ramchandani]

May I know why this case was closed as Duplicate? Also, why both cases were closed while they were being tracked as a proper bug with PoCs.

(In reply to Daniel Veditz [:dveditz] from comment #13)

We may already have a Fenix bug on the prompting issue

Share the case, please.

The case here is that we should actually be blocking external handler in iframe as one can do nefarious work with it. Like we block tel: URI in the iframe similarly Microsoft-edge should be blocked despite having a sandbox attribute there.

If the case is close, we should most probably be removing the visibility from private to public which can/will be used by other users for learning/chaining purpose.

Thanks!