1677138 - (CVE-2022-34474) sandboxed iframes can "redirect" to external schemes

Status: RESOLVED FIXED

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

Description

[Tom Ritter [:tjr]]

Attachment: ad.html

This was sent into the security list:

We’ve recently discovered a malicious ad campaign that is taking advantage of iFrames to attempt to redirect the user to a different app. When the ad is served in an iFrame in the publisher page and ad server sends a redirect header, we have observed that Firefox in macOS and Android does not actually ignore these redirect attempts but asks the user the permission to redirect to the app even when the iFrame is appropriately sandboxed with allow-top-navigation-by-user-activation. We have so far tested this with the schemes listed below as the value of the "Location" parameter for the header:

MacOS Schemes

• "itms-apps://",
• "itms-appss://",
• "itms://",
• "itmss://",
• "https://itunes.apple.com/app/",
• "ibooks://",
• "itms-books://",
• "itms-bookss://",
• "contact://",
• "message://",
• "sms://",
• "music://",
• "musics://",
• "podcasts://",
• "itms-podcasts://",
• "podcast://",
• "tel://"

Android Schemes

• "Intent://"

For example, when the "Location" value of the header is "itms-apps://itunes.apple.com/app/id378458261", Firefox attempted to open the app with id id378458261 in AppStore in MacOS. When the "Location" value of the header is "intent://#Intent;package=com.vtaxi.app;S.market_referrer=appmetrica_tracking_id%253D602904027453287968%2526ym_tracking_id%253D9847664011024495609;end", Firefox redirected to the Google Play page of that app.

I have produced a working POC with Firefox 78.4.0esr (64-bit) on my macOs 10.15.7 and with Firefox 82.1.3 (Build #2015774645) on Pixel 4 with Android 11.

I have also attached the proof of concept code that performs the attack. I have produced a working POC using the setup I described below:

1. Run malicious-ad-server.py with python3 to serve ad.html in an iFrame using ngrok on port 8000.

2. Run publisher.py with python3 to serve PUBLISHER-DOMAIN/safe and PUBLISHER-DOMAIN/unsafe paths using ngrok, on a different machine than the malicious server. (You also need to change "src" value of the iFrames in publisher.py to "MALICIOUS-SERVER-DOMAIN/ad.html"). PUBLISHER-DOMAIN/unsafe serves the ad in an iFrame without sandbox attributes whereas PUBLISHER-DOMAIN/safe serves the ad in a sandboxed iframe with attributes:

• "allow-top-navigation-by-user-activation"
• "allow-forms"
• "allow-pointer-lock"
• "allow-popups"
• "allow-popups-to-escape-sandbox"
• "allow-same-origin"
• "allow-scripts"

3. Using a 3rd device, visit publisher site's /safe and /unsafe pages.

Comment 1

[Tom Ritter [:tjr]]

Attachment: malicious-ad-server.py

Comment 2

[Tom Ritter [:tjr]]

Attachment: publisher.py

Comment 3

[Tom Ritter [:tjr]]

After clarifying, they confirmed this was an issue on macOS (Desktop) and Firefox for Android; not Firefox for iOS.

I'm moving the the OSX component but the Fenix fix may be different...

Comment 4

[:Gijs (he/him)]

If the navigation happens that's an issue with iframe sandboxing, not with cocoa widget code, so moving over there.

Note that from the attached testcase, I guess the frame has:

sandbox="allow-top-navigation-by-user-activation allow-forms allow-pointer-lock allow-popups allow-popups-to-escape-sandbox allow-same-origin allow-scripts"

so I think this is maybe expected, because of allow-popups and allow-popups-to-escape-sandbox ? But I am not au fait with the current discussions around sandboxing, so perhaps Anne or Christoph can look?

This also feels like something we have on file, perhaps not as a sec bug, but I don't have a bug to hand.

Comment 5

[Anne (:annevk)]

Johann and Paul are tackling non-browser URL schemes so I'll let them speak to this. (See also bug 1565574.)

Comment 6

[Johann Hofmann [:johannh]]

So, without having run the POC, is it correct to summarize that the issue is that iframes can open external protocols without user interaction, even in a sandbox?

I think we're currently coming to the conclusion that even without a sandbox, this capability might be problematic for most protocols, which is what we're trying to change in https://github.com/whatwg/html/issues/6111 by adding a permissions policy attribute to restrict this by default. Paul is currently adding Telemetry for that.

Independent of that there's probably still a bug here, though, as the navigation itself shouldn't happen because of the sandbox? I haven't looked into that. It seems like a valid security issue.

Comment 7

[Anne (:annevk)]

With respect to allow-popups-to-escape-sandbox, is the link opened in a popup-way, e.g., with a target attribute or window.open()? Otherwise it seems that should not apply (although maybe, the rules on these URL schemes are not written down) and only allow-top-navigation-by-user-activation would be the potential escape here (if there was user activation).

Comment 8

[Johann Hofmann [:johannh]]

(Note that popups also need user activation to open)

Comment 9

[Emma Zühlcke [:emz]]

(In reply to Johann Hofmann [:johannh] from comment #6)

Independent of that there's probably still a bug here, though, as the navigation itself shouldn't happen because of the sandbox? I haven't looked into that. It seems like a valid security issue.

Yes, I think we shouldn't allow the prompt / forward to the protocol handler in this case.
The problem is probably that the actual navigation to the external protocol is not happening top level, but in the frame. We then prompt and open the handler either top level in a new tab (web handler) or launch the external application. Perhaps navigation to external protocols should always be treated as a top level navigation sandbox wise, since we handle it that way.

Comment 10

[Johann Hofmann [:johannh]]

Paul, can you test what other browsers are doing here? Is it worth including sandboxed as a key in our new telemetry?

Thanks!

Comment 11

[Emma Zühlcke [:emz]]

The telemetry for Bug 1672344 now also checks for null principal.

Comment 12

[amazon.malvertising.outreach]

Hi Mozilla security,

This vulnerability is being actively exploited in the wild. Do you have an ETA for a fix?

Thanks,
Amazon malvertising team

Comment 13

[Emma Zühlcke [:emz]]

Side note: Since the change in Bug 1679456 we're requiring user activation for frames to redirect to external protocols. This should partially mitigate this issue.

Comment 14

[Johann Hofmann [:johannh]]

We should check that bug 1680721 will keep this bug fixed and close it as resolved then. Depending on the frequency of this being exploited in the wild we should have a follow-up discussion around whether we can uplift that changeset to Beta.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Yeah, I think the main question is whether we want to uplift those patches and turn dom.delay.block_external_protocol_in_iframes.enabled=false everywhere (which should be fine).

I'm not on mac but I suspect that bug will keep it fixed, if my reading of comment 0 is right, as it relies on a cross-origin iframe which wouldn't be allowed to do this without user-activation.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Ah, hold on, or maybe not, if the frame is embedded by the top level page. We should still probably have tighter checks for sandboxed frames in any case though.

Comment 17

[Johann Hofmann [:johannh]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #15)

Yeah, I think the main question is whether we want to uplift those patches and turn dom.delay.block_external_protocol_in_iframes.enabled=false everywhere (which should be fine).

Yes that would be my suggestion, too.. I can't really imagine that we'd be breaking a lot of sites by going from "every 10s" to "once then with user interaction". (Unless I'm misinterpreting the effect of that pref here)

I'm not on mac but I suspect that bug will keep it fixed, if my reading of comment 0 is right, as it relies on a cross-origin iframe which wouldn't be allowed to do this without user-activation.

Yes, this is about sandboxed iframes specifically, which are always cross-origin. I guess

Ah, hold on, or maybe not, if the frame is embedded by the top level page. We should still probably have tighter checks for sandboxed frames in any case though.

If it's cross-origin (e.g. an opaque origin) it should still not get the free initial protocol navigation without user interaction, right? So we're a bit better already.

The complete fix to this bug is probably to enact the sandbox restrictions proposed in https://github.com/whatwg/html/issues/2191. So it makes sense to leave it open to track that work.

Reporter, did you report this issue to other browser vendors? Looking at the standards issue this should be an issue in other browsers, too.

Thanks!

Comment 18

[amazon.malvertising.outreach]

Reporter, did you report this issue to other browser vendors? Looking at the standards issue this should be an issue in other browsers, too.

Thanks!

Yes, we have reported this issue to Chrome security team as well.

Comment 19

[amazon.malvertising.outreach]

Hi Firefox Security teams,

After 90 days we will share the vulnerability with selected trusted threat sharing partners regardless of whether it has been fixed in order to protect end users.

Thanks,
Amazon malvertising team

Comment 20

[Neha Kochar [:neha]]

Anne, what is your recommendation for next steps here? Looks like Chrome's bug is closed as wontfix.

Comment 21

[Anne (:annevk)]

Do you have a reference to Chrome's bug? I don't see it.

There's two pieces here:

1. How to deal with custom URL schemes in general. Bug 1626068 will tackle that.
2. How to deal with them in sandboxed environments as pointed out in comment 17. The solution from https://github.com/whatwg/html/issues/2191 to only allow fetch schemes in a sandboxed environment seems still rather attractive, but would require some amount of investigation.

(Also, initially we allowed this without user activation which is no longer the case. So it's not clear to me this bug needs to remain closed.)

Comment 22

[Neha Kochar [:neha]]

Oh, the Chrome's bug that I was referring is for #2 from comment 17. The bug is https://bugs.chromium.org/p/chromium/issues/detail?id=329000 which is referenced from https://github.com/whatwg/html/issues/2191 .

Comment 23

[Anne (:annevk)]

I see, that's an old bug specific to iOS, so I would expect Chrome to still be willing to make changes here as per Mike West's comments in the HTML issue.

Comment 24

[Andrew McCreight [:mccr8]]

Johann, what's the status here? You talked about some other bug being fixed, and it has been fixed. Thanks.

Comment 25

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

This bug needs to be verified on Fenix and Focus Android too. Who can help with that?

Comment 26

[amazon.malvertising.outreach]

Hi Firefox Security teams,

We have tested the vulnerability again on Firefox 92.0 (64 bit) on Mac and we can confirm that the vulnerability is not fixed.

Could you give an update on the ETA please?

Thanks,
Amazon malvertising team

Comment 27

[Johann Hofmann [:johannh]]

Both Chrome and us are still waiting on Microsoft Teams to ship an update that adds the correct sandbox flags before we can start enacting the restriction proposed in https://github.com/whatwg/html/issues/2191.

Paul (:pbz) is directly in contact with Microsoft and will follow-up once they get to a solution.

Comment 28

[Hsin-Yi Tsai (she/her) [:hsinyi]]

After chatting with Ethan, assigning to Paul and adjusting the priority.

Comment 29

[:Gijs (he/him)]

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

After chatting with Ethan, assigning to Paul and adjusting the priority.

Going to assume you meant to actually assign, not make Paul the mentor...

Comment 30

[Emma Zühlcke [:emz]]

Looks like we have alignment with Microsoft now. They've submitted a PR to add a new sandbox flag allow-top-navigation-to-custom-protocols. There is also a patch for Chromium, behind a feature flag: https://chromestatus.com/feature/5680742077038592
I think we can follow this approach and start enforcing sandbox for custom protocol navigation in Nightly.

Comment 31

[Emma Zühlcke [:emz]]

I've submitted patches in Bug 1735746.

Comment 32

[Tom Ritter [:tjr]]

Attachment: advisory.txt