940278 - Install and launch intents on for webapps on Android can be spoofed.

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: Web Apps (PWAs), defect, P1)

Description

[Mark Goodwin [:mgoodwin]]

Issue:

WebApps on Android are to be delivered via synthesized APKs which install and launch themselves via intents sent to Fennec.  From discussions with Myk and James it seems there is no mechanism to prevent malicious Android applications from mimicking these intents.

Consider the following scenario:
1) A privileged web app is created which requests all permissions (this may or may not be created with malicious intent)
2) An attacker obtains the synthesized APK for this web app and determines what intents are sent to Fennec on first / subsequent invocations.
3) An attacker creates their own malicious Android application which mimics the intents sent by the android stub in the web app's APK which masquerades as a legitimate app (e.g. a game) and submits the APK to Google Play.
4) A victim finds the attacker's app (either directed by the attacker or by chance) and installs it, noting that the app requests no (or minimal) Android permissions.
5) The victim runs the malicious app, which then installs (and invokes) the privileged web app resulting in privileged APIs being called (and potential exfiltration of user data) without the victim's consent.

Comment 1

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Mark Goodwin [:mgoodwin] from comment #0)
> Issue:
> 5) The victim runs the malicious app, which then installs (and invokes) the
> privileged web app resulting in privileged APIs being called (and potential
> exfiltration of user data) without the victim's consent.

Two details here. First, the permissions are associated with the web app, not the intent. So the malicious app wouldn't get any additional permissions. Second, if the malicious app mimics the intent for the web app, they'd just wind up launching the web app.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

I was going to point out the same thing as Brad. Step #5 is where the attack falls apart. The malicious APK doesn't get access to any of the webapp data or privileged APIs. The malicious APK only has the permissions it actually requested to use to access data on the phone through normal Android APIs, but not through the webapp or any web APIs.

Comment 3

[Mark Goodwin [:mgoodwin]]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #1)
> Two details here. First, the permissions are associated with the web app,
> not the intent. So the malicious app wouldn't get any additional
> permissions. Second, if the malicious app mimics the intent for the web app,
> they'd just wind up launching the web app.

The issue here isn't that the malicious Android app magically gets permissions (as you've said it doesn't).

The issue is that, from my understanding - and Myk and James seemed to agree, there's nothing to stop a malicious Android app (with no Android permissions) installing and running a web app (malicious or otherwise) with all web app permissions. Am I wrong?

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Mark Goodwin [:mgoodwin] from comment #3)

> The issue is that, from my understanding - and Myk and James seemed to
> agree, there's nothing to stop a malicious Android app (with no Android
> permissions) installing and running a web app (malicious or otherwise) with
> all web app permissions. Am I wrong?

It's the "with all web app permissions" that we need to figure out. As I understood it, we are not automatically giving webapps unprompted access to webapis. If a webapp wants to access your contacts, the user would still be prompted.

If that is not the case, then we have a problem. Similar to add-ons, we might need to somehow whitelist stores when we get a mini-manifest (or whatever the heck it is).

Comment 5

[Mark Goodwin [:mgoodwin]]

(In reply to Mark Finkle (:mfinkle) from comment #4)
> It's the "with all web app permissions" that we need to figure out. As I
> understood it, we are not automatically giving webapps unprompted access to
> webapis. If a webapp wants to access your contacts, the user would still be
> prompted.

As per:

http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsTable.jsm#35

there are a bunch that are allowed without prompts. Including stuff like System XHR and audio channel.

Comment 6

[Wesley Johnston (:wesj)]

IF we decide we need something here, we could, at install of any app via intent, do a permissions cross check using something like:

https://developer.android.com/reference/android/content/pm/PackageManager.html#checkPermission%28java.lang.String,%20java.lang.String%29

Comment 7

[Mark Goodwin [:mgoodwin]]

Do we intend to allow flows where the APK is obtained via routes other than navigator.mozapps.install?

Comment 8

[Myk Melez [:myk] [@mykmelez]]

(In reply to Mark Goodwin [:mgoodwin] from comment #7)
> Do we intend to allow flows where the APK is obtained via routes other than
> navigator.mozapps.install?

Yes, we intend to allow at least two such flows, and we plan to support one of them (but not the other, at least not initially).

The one we're going to allow and support is a development flow in which a developer builds an APK on their desktop and then pushes it to an Android device in order to test their app before uploading it to Marketplace.

The one we'll allow (but won't initially support) is a developer distributing their APK on Android marketplaces like Google Play.

Comment 9

[Mark Goodwin [:mgoodwin]]

OK, I was wondering whether we could rely on navigator.mozapps.install populating a whitelist of webapps which could be installed from intents.

We could still do this but have non-whitelisted items give a user prompt (this would be in addition to the mechanism for permission cross-checking Wes mentioned in comment 6).

Comment 10

[James Hugman [:jhugman] [@jhugman]]

So the concern is that a badly written webapp can be exploited by a malicious native app.

A badly written webapp that responds to a WebActivity by doing something privileged/certified. Whether or not there is a permission prompt, the permission prompt may have already been accepted in the lifetime of the app.

The evil APK fires off a carefully crafted intent intended for the webapp. The webapp responds without notifying the user.

c.f. browsers on Android which respond to BROWSEABLE intent, which causes the browser to load and execute a page.

I not really convinced that either this is a) a problem b) if it is a problem, that it is a large problem.

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

Hi Mark, can you help us get consensus on the sec- rating here? (and next steps)

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

Can we get an example webapp to use for real world testing? I'd like to see what Web APIs we give unprompted access. I think we only care about Web APIs that provide access to data that is outside the webapp's profile.

Contacts comes to mind, but that seems to be listed as PROMPT
Device Storage would be affected too, but is DENY or PROMPT.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Perhaps KitchenSink <https://marketplace.firefox.com/app/kitchensink>?  It asks for contacts, among other things, although I'm unsure how to make it actually use that API.

Comment 14

[David Bolter [:davidb] (NeedInfo me for attention)]

If comment 13 doesn't work here maybe Mark Goodwin knows other good example webapps? (see comment 12)

Comment 15

[Andrew McCreight [:mccr8]]

Any updates here?

Comment 16

[Mark Goodwin [:mgoodwin]]

(In reply to David Bolter [:davidb] from comment #14)
> If comment 13 doesn't work here maybe Mark Goodwin knows other good example
> webapps? (see comment 12)

I don't know any example webapps but we could always write one.  So far as I can tell, none of the privileged APIs that are scary are supported. Yet.

From a skim down the list in comment 5, the first scary-ish permission looks to be tcp-socket. Then system-XHR. Then a bunch of media and device related things.

(In reply to James Hugman [:jhugman] [@jhugman] from comment #10)
> So the concern is that a badly written webapp can be exploited by a
> malicious native app.

Not quite. It's more that a malicious native app (even with no permissions) could persuade Fennec to install *any* web app (badly written, malicious or otherwise).

Comment 17

[Al Billings [:abillings - ex-MoCo]]

Critsmash looking at old, stale sec-high rated issues here. Is there anything we can do to move this along towards getting fixed? I don't know if you can take this one on?

Comment 18

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Mark Goodwin [:mgoodwin] from comment #16)
> (In reply to David Bolter [:davidb] from comment #14)
> > If comment 13 doesn't work here maybe Mark Goodwin knows other good example
> > webapps? (see comment 12)
> 
> I don't know any example webapps but we could always write one.  So far as I
> can tell, none of the privileged APIs that are scary are supported. Yet.

That is the first reason we should just close this bug for now.

> 
> From a skim down the list in comment 5, the first scary-ish permission looks
> to be tcp-socket. Then system-XHR. Then a bunch of media and device related
> things.

This is the second reason. tcp-socket and system-XHR might be scary for pure web content, but we are talking about someone creating an Android APK here. These APIs are not even close to scary.

> 
> (In reply to James Hugman [:jhugman] [@jhugman] from comment #10)
> > So the concern is that a badly written webapp can be exploited by a
> > malicious native app.
> 
> Not quite. It's more that a malicious native app (even with no permissions)
> could persuade Fennec to install *any* web app (badly written, malicious or
> otherwise).

What does this gain the malicious developer? The webapp is run from it's own empty profile. You can't grab browsing data or cookies.

Maybe I am still badly missing the point though. If the attack is through the user installing a malicious Android APK, the user has bigger, non-Gecko problems, right?

Comment 19

[Al Billings [:abillings - ex-MoCo]]

Mark Goodwin, in light of comment 18, should we close this? 

Otherwise, this is a sec-high which is a year old and not getting addressed at this point.

Comment 20

[Mark Goodwin [:mgoodwin]]

(In reply to Al Billings [:abillings] from comment #19)
> Mark Goodwin, in light of comment 18, should we close this? 
> 
> Otherwise, this is a sec-high which is a year old and not getting addressed
> at this point.

What an attacker gains is the ability to use privileges that the user hasn't agreed to.

There's still a bug here, though while exposure is limited to these APIs it's not sec-high (at the time of filing, my understanding was we'd be adding new privileged APIs so the impact looked rather worse).

We could close if we're confident we'll remember the attack should we ever expose new priv. APIs, or we could re-rate it. I don't really mind.

Comment 21

[James Hugman [:jhugman] [@jhugman]]

> a malicious native app (even with no permissions)
> could persuade Fennec to install *any* web app
This is true. The new app would appear in the about:apps page (which may be visible to the user). The new app wouldn't be visible in the app drawer as a different APK.

Permissions for the new web app would be silently accepted. Any access to the device by the webapp would go through the normal web api security prompts.

If these aren't working as intended, then that'd be the front line of this problem - it is certainly unclear to me the rules on default actions nowadays.

The new web app isn't very findable to launch it accidentally, but this may become more of an issue if coupled with WebActivities. 

> persuading Fennec
I'm not really sure how to flag this to the user. Providing a custom android permission to ask fennec to install webapps would be a good first stab at this. I'm unsure what the behaviour is where the malicious APK is installed before Fennec.

Alternatives that involve Fennec verifying that the app is a genuine Synthesized APK™ is problematic from a developer ergonomics point of view, and makes it impossible to spin up your own instance of the APK factory.

Comment 22

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Mark Goodwin [:mgoodwin] from comment #20)
> (In reply to Al Billings [:abillings] from comment #19)
> > Mark Goodwin, in light of comment 18, should we close this? 
> > 
> > Otherwise, this is a sec-high which is a year old and not getting addressed
> > at this point.
 
> What an attacker gains is the ability to use privileges that the user hasn't
> agreed to.
>  There's still a bug here, though while exposure is limited to these APIs
> it's not sec-high (at the time of filing, my understanding was we'd be
> adding new privileged APIs so the impact looked rather worse).
No additional APIs are exposed, so I don't think there is a big here. Let's reclassify, I don't think this is any thing more than a sec-low. 
> We could close if we're confident we'll remember the attack should we ever
> expose new priv. APIs, or we could re-rate it. I don't really mind.

Comment 23

[Myk Melez [:myk] [@mykmelez]]

Per bug 1235869, we're going to disable the Android web runtime, so we won't fix this bug in it.

(This is part of a bulk resolution of bugs in the Firefox for Android::Web Apps component, from which I attempted to exclude bugs that are not specific to the runtime, but it's possible that I included one accidentally.  If so, I'm sorry, and please reopen the bug!)

Comment 24

[David Lawrence [:dkl]]

Removing employee no longer with company from CC list of private bugs.