Closed Bug 981550 Opened 9 years ago Closed 9 years ago
Apps can cause permissions prompts in other apps
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.
Paul - Can you reproduce this with other PROMPT_ACTION WebAPIs? I want to know if this is specific to gUM or not.
I got the impression from alive that this was an existing bug, but I will try to reproduce on other permissions.
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
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
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.
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.
blocking-b2g: --- → 1.4?
Summary: Apps can cause permissions prompts in other apps by using setTimeout → Apps can cause permissions prompts in other apps
(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?
Seems clean the pending requests while press home/holdhome can fix it before we done bug 852013 and bug 853711 .
Assignee: nobody → gasolin
Comment on attachment 8391025 [details] [review] pull request redirect to github Unit test fails!
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 on attachment 8391025 [details] [review] pull request redirect to github Please add unit test.
Attachment #8391025 - Flags: review?(alive) → review+
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.
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?
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Paul - What do you want to do here?
blocking-b2g: 1.4? → ---
Flags: needinfo?(jsmith) → needinfo?(ptheriault)
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.
(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.
You need to log in before you can comment on or make changes to this bug.