1584582 - (CVE-2021-23957) iframe sandboxing bypass on Android via intent: url scheme

Status: RESOLVED FIXED

(Fenix :: General, defect, P1)

Description

[Eliya Stein]

Hi Team,

This bug is actively being exploited by a prolific malvertiser known as Zirconium in order to serve millions of forced mobile redirections via malicious ad campaigns.

Here's a reference for more information about Zirconium:

https://blog.confiant.com/uncovering-2017s-largest-malvertising-operation-b84cd38d6b85

The bug:

Consider an iframe with the following sandboxing attributes:

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

These are standard sandbox attributes for ad serving, and they're generally meant to mitigate things like forced redirections that are uninitiated. Especially the "allow-top-navigation-by-user-activation" attribute.

Most browsers will block something like this in such an iframe:

top.location.href="http://malicious_landing_page";

Firefox on Android will prevent this redirection as well. However, it will not prevent spawning a redirect that's done in this manner:

location.href = "intent://malicious_landing_page/#Intent;scheme=https;package=com.android.chrome;end";

This payload will spawn Google Chrome from Firefox and open the malicious page without any user interaction. It will also spawn if the allow-popups attribute isn't present. All other major browser successfully prevent this.

This is currently being heavily abused in an ongoing malvertising campaign which is specifically targeting Firefox on Android. We strongly recommend that this be addressed with some urgency as that will have a direct impact on the malvertiser's financial success with this campaign.

This has been tested in the latest Firefox on Android 9 - Samsung Galaxy S8+ as well as several Browserstack instances.

Happy to answer any questions you might have.

Best,
Eliya

Comment 1

[Johann Hofmann [:johannh]]

Chris, Stefan, who is responsible for handling security bugs for Fennec these days? Can you please get this in the right hands? Thank you.

Comment 2

[Chris Peterson [:cpeterson]]

Thanks for the heads up, Eliya.

location.href = "intent://malicious_landing_page/#Intent;scheme=https;package=com.android.chrome;end";

@ Christoph and James: Fennec allows malicious JS to open ad pages in Chrome (using intent: URIs) without user interaction. Does this sound like a Gecko bug or a Fennec/GeckoView bug?

The Chrome team announced that forced redirects will be blocked in Chrome 64 scheduled for release on January 23.

Comment 3

[Chris Peterson [:cpeterson]]

Chris, Stefan, who is responsible for handling security bugs for Fennec these days?

To answer your question: Stefan (Fennec engineering manager) and Ashley Thomas (Fennec product manager) are currently responsible for Fennec bug triage.

Comment 4

[Daniel Veditz [:dveditz]]

I think we have to call this "sec-moderate", but that doesn't mean it's not important and urgent to address a campaign in progress.

intents are effectively the same kind of evil as external helper apps or external content handlers on Desktop. We shouldn't be loading any that aren't on an explicit whitelist without asking the user first (an option to "remember this" is fine after that first ask).

Comment 5

[Eliya Stein]

Hi Daniel,

For what it's worth, I absolutely agree with what your'e saying and the whitelist approach, but it might be more secure to forbid an iframe from loading an intent without any user activation in the first place.

Just for some reference/context, I believe Chrome made a decision along these lines at some point:

https://developer.chrome.com/multidevice/android/intents

From my testing, it make sense. The functionality is still there if there's a link in the iframe along the lines of <a href="intent:..., but the scenario where a bad actor can cause forced actions is mitigated. It would still be a bit weird if a third party ad can land on a site and this causes the user to be prompted to open chrome or open slack for example.

Best,
Eliya

Comment 6

[James Willcox (:snorp) ([e-mail]) (he/him)]

I think we tried a long time ago to require user interaction here in Fennec but it had some problems. We're facing a similar thing in GeckoView now (bug 1555337), which is why Fenix doesn't support intent urls yet.

Can we just disallow intent urls in iframes entirely? Or will that break some kind of login flow somewhere?

Comment 7

[Chris Peterson [:cpeterson]]

Can we just disallow intent urls in iframes entirely? Or will that break some kind of login flow somewhere?

Who should make this decision? ckerschb? snorp?

If we don't know of any breakage, we could disable intent URIs in GeckoView Nightly and see if anyone complains. Or we could ask QA to do some manual testing of a build with intent URIs disabled.

Comment 8

[Chris Peterson [:cpeterson]]

If we disable intent URIs in GeckoView/Fenix without any big problems, would we backport this patch to Fennec ESR 68?

Comment 9

[Chris Peterson [:cpeterson]]

James says this is a Fenix bug. Fenix is not vulnerable at the moment, but might be after they implement support for intent URIs. This bug can be a reminder to test this case in Fenix then.

firefox-esr68=wontfix because we won't fix for Fennec.

Comment 10

[Eliya Stein]

Hi Team,

We are hoping to publish some research in the next few weeks on how this malvertiser leverages these types of browsers quirks in order to maximize the impact of their campaigns. This example is a great case and we would like to talk about it pubclicly. Can you please let us know if this interferes with your efforts towards a fix? If so, what do you consider a reasonable timeline?

Best,
Eliya

Comment 11

[Daniel Veditz [:dveditz]]

needinfo Chris for comment 10, since the talk would presumably include our shipping product (Fennec) where this is wontfixed and not our not-yet-release Fenix.

Can we just disallow intent urls in iframes entirely? Or will that break some kind of login flow somewhere?

Without telemetry I don't see how we can answer this (or shipping the change to see what breaks). I suspect most "open me in this app" will be links and not iframes, but that's an uneducated guess.

Comment 12

[Chris Peterson [:cpeterson]]

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

needinfo Chris for comment 10, since the talk would presumably include our shipping product (Fennec) where this is wontfixed and not our not-yet-release Fenix.

Can we just disallow intent urls in iframes entirely? Or will that break some kind of login flow somewhere?

Without telemetry I don't see how we can answer this (or shipping the change to see what breaks). I suspect most "open me in this app" will be links and not iframes, but that's an uneducated guess.

^ redirecting to Emily Toop, GeckoView engineering manager.

(I'm no longer working on GeckoView these days.)

Comment 13

[Emily Toop (:fluffyemily)]

This bug does not affect Fenix, only Fennec and so is not required.

Comment 14

[Daniel Veditz [:dveditz]]

It was filed against Fennec and is NOT "invalid" -- it's an active malvertising campaign. It got bounced to GeckoView in the mistaken assumption it was backend code, and then bounced back to the wrong front-end where the abused feature is not (yet?) supported. Moving back. Maybe it's wontfix given our intended migration to Fenix in that case, but not invalid.

Comment 15

[Kevin Brosnan [Ex-Mozilla]]

Agi/Christian we should verify Fenix/GV example behavior on this. AFIK we have implemented intent handling code in Fenix so this should still apply if we have not made any mitigations.

Comment 16

[Kevin Brosnan [Ex-Mozilla]]

Agi is on PTO

Comment 17

[Christian Sadilek [:csadilek]]

I've verified that this is reproducible in Fenix and needs a fix in A-C's AppLinksInterceptor. We should check if it the load request is a subframe request and not handle/intercept it in this case.

Adding Roger.

Comment 18

[Roger Yang [:royang]]

Attachment: applinks_subframe_request.patch

Comment 19

[Christian Sadilek [:csadilek]]

Comment on attachment 9193055 [details] [diff] [review]
applinks_subframe_request.patch

Review of attachment 9193055 [details] [diff] [review]:
-----------------------------------------------------------------

I've verified this prevents the forced redirect described above. Let's add a unit test for this case before landing on GH.

Comment 20

[Roger Yang [:royang]]

I've verified this prevents the forced redirect described above. Let's add a
unit test for this case before landing on GH.

Understood. Thanks

Comment 21

[Roger Yang [:royang]]

Fix merged in Android Component

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Can you please include a link to the AC commit that fixed this? Also, which AC version is it shipping in?

Comment 23

[Roger Yang [:royang]]

Sure, this is the pr https://github.com/mozilla-mobile/android-components/pull/9218. This change was merged in AC 70. Thanks,

Comment 24

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Comment 25

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Comment 26

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Comment 27

[Eliya Stein]

Hey Freddy - Is it appropriate to reference this CVE publicly yet? At what point does this issue become public?

Thanks,
Eliya

Comment 28

[Kevin Brosnan [Ex-Mozilla]]

The 85.1.0 and 85.1.1 builds has been at a 25% rollout until about 10 Pacific/18 UTC today. We bumped to 99% and are planning on going to 100% early next week baring any major issues cropping up. Until we push to 100% there is no way for Google Play users to force the update. It is just how the Play Store works.

A few weeks after that should be fine see previous example in bug 1659381 comment 19 and bug 1659381 comment 23

Comment 29

[Eliya Stein]

Thanks Kevin!