Prevent background apps from launching Web Activities

RESOLVED FIXED in Firefox 18

Status

P2
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: pauljt, Assigned: mounir)

Tracking

unspecified
B2G C2 (20nov-10dec)
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)

Details

(Whiteboard: [fixed by bug 794407])

(Reporter)

Description

6 years ago
Apps can currently initiate web activities from the background. No background app should be able to influence anything displayed (unless they have the attention_screen permission) to the user as this might lead to security problems. I think this will probably be mitigated by bug 794407 but wanted to call it out explicitly to make sure.
All list menu based XXXX menus have the same problem.
Assignee: nobody → alive
(Assignee)

Comment 2

6 years ago
Paul, what kind of "explicit fix" are you looking for? I feel like trying to fix something for "background apps" might be hard unless this is a hack because the platform doesn't really have such a concept (it's currently a Gaia hack).
Do you expect background apps to simply not call activities? I feel like bug 794407 would be enough to prevent that.
Alive, what fix do you have in mind?
OS: Mac OS X → All
Hardware: x86 → All
(Reporter)

Comment 3

6 years ago
So my understanding of the Window Manager in Gaia is that there is always one app which is currently the foreground app. I thought it was a security requirement that only the current foreground app can display anything on the screen, with the exception of the attention screen (or the system app I suppose). If a background app can show things to the user, or somehow interfere with the foreground app, this might lead to security issues. 

In this specific case, I can't think of an exploitation case off the top of my head, but I haven't really looked at web activities all that much yet. The main reason I lodged this bug was that I wasn't certain that  bug 794407 would effectively exclude this from happening, but if you are comfortable that it does, then I am happy to mark this as a dupe. 

Alive, can you elaborate on what you mean by 'all the list based xxxx menus have the same problem'?
Assignee: alive → nobody
Sorry I know less about gecko but I don't see anywhere the patch deals with app visibility. Maybe it does.

For gaia, activity menu is based on list menu, which doesn't prevent background app to request a menu.
Context menu is also based on list menu in system app so it has the same problem. This should be fixed later, but maybe we are O.K. to ship with it. I have no idea if gaia could know who(app) is asking an activity.
(Reporter)

Comment 5

6 years ago
Ok I see what you mean. But as you say, at this point: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/activities.js#L27

You only have the detail object, and as far as I cant work it, it doesn't have the origin of the original caller.

What I was thinking of, was something like the check in navigator.pay (checking docshell.active): http://mxr.mozilla.org/mozilla-central/source/dom/payment/Payment.js#50

But I'll it up to you Mounir - TBH I dont completely understand how nsEventStateManager::IsHandlingUserInput() works, but if you are comfortable that this control will prevent background apps spawning activities I think that will be ok.

I assume there might still be an edge case like if an app fired an activity on close or something, but again, I can't see how an attacker could use that to their advantage. What I am more concerned about is background apps using activities to confuse the user as to what is the foreground app. (and given the app change animations I think this may be unlikely anyways)
Is this a security requirement for v1?

Updated

6 years ago
Component: Gaia → Gaia::Apps Management
(Reporter)

Comment 7

6 years ago
I think it should be, but decision isnt really up to me. This is a broader problem I think for Gaia since there are few ways that background apps can interfere with the foreground app. My understanding from previous bug discussion was that it was a requirement that an app that is not foreground cant display anything to the screen. This is the simplest from  a security perspective (i know the implementation isnt simple). Otherwise, if we allow it, we need to consider all of the edge cases where this behavior might be used for an attack and I don't think we will be able to do that comprehensively. I am trying to do some testing to figure out how extensive this problem is and how much work is needed to solve it.
I'll nom it just in case to get on this triage radar then.
blocking-basecamp: --- → ?
Component: Gaia::Apps Management → General
blocking-basecamp: ? → +
Priority: -- → P2

Comment 9

6 years ago
Milestoning for C2 (deadline of 12/10), as this meets the criteria of "known P2 bugs found before or during C1".
Target Milestone: --- → B2G C2 (20nov-10dec)
(Assignee)

Comment 10

6 years ago
(In reply to Paul Theriault [:pauljt] from comment #5)
> But I'll it up to you Mounir - TBH I dont completely understand how
> nsEventStateManager::IsHandlingUserInput() works, but if you are comfortable
> that this control will prevent background apps spawning activities I think
> that will be ok.

IsHandlingUserInput() will return true if the call is made in an event input handler, roughly. It seems hard to abuse that in a background app.
(In reply to Mounir Lamouri (:mounir) from comment #10)
> (In reply to Paul Theriault [:pauljt] from comment #5)
> > But I'll it up to you Mounir - TBH I dont completely understand how
> > nsEventStateManager::IsHandlingUserInput() works, but if you are comfortable
> > that this control will prevent background apps spawning activities I think
> > that will be ok.
> 
> IsHandlingUserInput() will return true if the call is made in an event input
> handler, roughly. It seems hard to abuse that in a background app.


Exact. Because of this I would say this bug is now blocking-basecamp-. Renoming.
blocking-basecamp: + → ?
(Assignee)

Comment 12

6 years ago
I would keep it as blocking because it requires bug 794407 to be fixed. As long as bug 794407 isn't fixed, background apps can launch activities. Given that the blocker of bug 794407 isn't really moving, I wouldn't be against some pressure to make bug 794407 resolved.
(In reply to Mounir Lamouri (:mounir) from comment #12)
> I would keep it as blocking because it requires bug 794407 to be fixed. As
> long as bug 794407 isn't fixed, background apps can launch activities. Given
> that the blocker of bug 794407 isn't really moving, I wouldn't be against
> some pressure to make bug 794407 resolved.

The underlying Gaia issue is waiting for review. I expect it to land this week.

Updated

6 years ago
blocking-basecamp: ? → +
mounir, is this something you can work on?
Assignee: nobody → mounir
(Assignee)

Comment 15

6 years ago
AFAIK, there is nothing to do here. Bug 794407 makes Web Activities not launchable from outside an event handler so I do not see how a background app can start a Web Activity.

Feel free to reopen if that statement is wrong.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 794407]
status-firefox18: --- → fixed
status-firefox19: --- → fixed
You need to log in before you can comment on or make changes to this bug.