981550 - Apps can cause permissions prompts in other apps

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Attachment: 2014-03-10-18-22-45.png

If an app or a web page makes multiple permission prompts using setTimeout, permissions prompts can appear from background apps in foreground apps, causing weird results, like a camera prompt (getUserMedia) that has the remember me checklist. (see screenshot)

I'm filing this in gaia, but from a discussion with Alive, it sounds like there are platform changes that are needed (i.e. tell gaia the app location that is making the permission request, not just the name)


STR:

1. Navigate the FxOS Browser to http://people.mozilla.org/~ptheriault/gumtest.html
2. Press "Video" button
3. Instead of select "share" or "dont share", press the home button
4. Open an app that prompts for a permission (e.g. camera)
5. Choose share/don't share for the expected prompt

Expected result:
No additional prompts are shown.

Actual:
The prompt that was caused by the setTimeout will then be, above the second app (e.g the camera) but the description in the prompt will be the original requesting web page.

It doesn't seem to actually grant the permission, but that might just be because of the way gUM prompts every time. I need to test this with other permissions that require prompts. 

If it does actually grant the permission, this could be a somewhat serious issue.

Comment 1

[Jason Smith [:jsmith]]

Paul - Can you reproduce this with other PROMPT_ACTION WebAPIs? I want to know if this is specific to gUM or not.

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I got the impression from alive that this was an existing bug, but I will try to reproduce on other permissions.

Comment 3

[Paul Theriault [:pauljt] (no longer reading bugmail)]

My guess the problem is that when we press the home button, we cause the current permission request to be deny, but there is still a queue of permissions requests that need to be denied:

https://github.com/mozilla-b2g/gaia/blob/1584816093182199576467b63d8c7e19c035a3a8/apps/system/js/permission_manager.js#L418

Comment 4

[[e-mail]]

In 1.x all app share the same permission dialog. We could solve shared dialog related issue by fixing these bugs

- bug 852013 (gecko): Send PermissionRequestEvent from mozbrowser iframe, instead of mozChromeEvent 
- bug 853711 (gaia): move permission dialog into appWindow and bind to BrowserFrame

Comment 5

[(inactive after 6/18) Alive Kuo [:alive]]

http://mxr.mozilla.org/mozilla-central/source/b2g/components/ContentPermissionPrompt.js#291
There is a simple check in gecko to check the page visibility for the permission request but I wonder the check would fail at certain situation to cause this bug.

Comment 6

[Paul Theriault [:pauljt] (no longer reading bugmail)]

So this has nothing to do with setTimeout actually. This behavior occurs whenever an app requests multiple permissions. Pressing the home button only seems to cancel the first permission prompt. The next time you get a prompt, after you either share/dont share, you get the leftover prompts that werent cancelled. I just tested this with geolocation and contacts, but I suspect it applies to all. 

I am still not sure if these leftover prompts actually grant the permission or not, but I have no reason to suspect that they wouldnt. 

So is this an exploitable bug? I tend to think so. At a minimum, and web page can just spam x permission reuqests (need to use setTimeout here I think since I think the prompt is blocking, not sure?). From then on, permissions prompts in other apps are basically prevented, since the malicious apps permission request will show up after the legit prompt. This seems like an important fix, but I don't know how hard it is to fix.

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #5)
> http://mxr.mozilla.org/mozilla-central/source/b2g/components/
> ContentPermissionPrompt.js#291
> There is a simple check in gecko to check the page visibility for the
> permission request but I wonder the check would fail at certain situation to
> cause this bug.

Ah ok - so the permission prompts seem to get queued with the original app is visible somehow, and then show up again after another app causes a prompt. I am not sure what is causing the queueing behavior, I'll have to dig through the code further.

So the long term solution is bind prompts to the app window somehow (ie  as part of window manager changes). but this is probably not a 1.4 solution. Perhaps there is a simple solution that we can implement in gaia for 1.4 - I am thinking something like "Kill all pending permisisons request when the user presses the home button". But I need to figure out what is causing the queueing before I can propose that as a fix.

Comment 7

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

(In reply to Paul Theriault [:pauljt] from comment #6)
 
> I am still not sure if these leftover prompts actually grant the permission
> or not, but I have no reason to suspect that they wouldnt. 

Would be great to get a definitive here. Is there someone who can do (is doing) that?

Comment 8

[[e-mail]]

Seems clean the pending requests while press home/holdhome can fix it before we done bug 852013 and bug 853711 .

Comment 9

[[e-mail]]

Attachment: pull request redirect to github

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8391025 [details] [review]
pull request redirect to github

Unit test fails!

Comment 11

[[e-mail]]

Comment on attachment 8391025 [details] [review]
pull request redirect to github

Now It's all green and double test passed. Please kindly review it again

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8391025 [details] [review]
pull request redirect to github

Please add unit test.

Comment 13

[Jason Smith [:jsmith]]

Fred - For security bugs, we should not use the same commit message as the bug. Use a naming that doesn't hint at the security problem.

Comment 14

[[e-mail]]

Sorry I did not see the comment 13 before merged :(

https://github.com/mozilla-b2g/gaia/commit/ca537fbba22c94c878905bbacf28096d0f63a2ac

What can I do to amend this?

Comment 15

[Jason Smith [:jsmith]]

Paul - What do you want to do here?

Comment 16

[Paul Theriault [:pauljt] (no longer reading bugmail)]

This probably sec-moderate given the user interaction required to gain anything other than a DoS out of this vulnerability. Also malicious app would need to be privileged so marketplace review/response is an additional mitigating factor here.

Comment 17

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Jason Smith [:jsmith] from comment #15)
> Paul - What do you want to do here?

I.e. I am not too worried about landing the tests and fix at the same time. The title of this bug probably shouldnt have been included in the patch - we should avoid that in the future, but I dont think its too much of an issue for this specific bug.