Closed
Bug 820281
Opened 13 years ago
Closed 12 years ago
Make shell.js validate parameters to *-handler messages
Categories
(Firefox OS Graveyard :: General, defect)
Firefox OS Graveyard
General
Tracking
(blocking-basecamp:-)
RESOLVED
WONTFIX
| blocking-basecamp | - |
People
(Reporter: pauljt, Unassigned)
References
Details
As part of the URI handler code in shell.js, messages are sent from child and handled by shell.js. There is validation in each protocol handler, before sending the parameters, but this validation is not performed by the parent and could thus lead to attack from a compromised child process. THe messages in question are:
content-handler
This message launches a system web activity and is limited to the PDF mime type (http://dxr.mozilla.org/mozilla-central/b2g/components/ContentHandler.js.html#l34). This check should be enforced in the parent as well.
dial-handler
Telephone number is checked as being valid in the child, not the parent - should add a check in the parent to prevent malicious data being sent as a system initiated activity.
sms-handler
SMS number is checked as being valid in the child, not the parent - should add a check in the parent to prevent malicious data being sent as a system initiated activity.
mail-handler
This handler currently doesnt have checks in either the parent or the child. We might want to considering adding some validation (e.g. email address) in the parent to harden this interface.
| Reporter | ||
Updated•13 years ago
|
Component: DOM: Device Interfaces → DOM: Apps
OS: Mac OS X → All
Hardware: x86 → All
Updated•13 years ago
|
Component: DOM: Apps → General
Product: Core → Boot2Gecko
| Reporter | ||
Comment 1•13 years ago
|
||
Shell.js also handles the |app-notification-send| message, used to send a notifications (I think). A compromised child could spoof a notification as if it came from any application. Parent should check to ensure that app is only sending notifications for itself..
Comment 2•13 years ago
|
||
Is this necessary for v1? If so, please nominate for b-b?
| Reporter | ||
Comment 3•13 years ago
|
||
Actually on reflection, and further understanding of activities, all of these actually just result in a web activity.[1] Since any content can start an activity, I think maybe there is no benefit for the attacker to spoof these messages. Can anyone else confirm this for me?
[1] http://dxr.mozilla.org/mozilla-central/b2g/chrome/content/shell.js.html#l511
blocking-basecamp: --- → ?
Flags: needinfo?
Updated•13 years ago
|
Flags: needinfo? → needinfo?(fabrice)
Comment 4•13 years ago
|
||
That's correct, these are messages used to bridge internal protocols to web activities. So even if an attacker spoof such a message, we go through all the web activities launch process, including showing an activity picker to the user.
Flags: needinfo?(fabrice)
Updated•13 years ago
|
blocking-basecamp: ? → -
Comment 5•12 years ago
|
||
koi? since it blocks bug 820202 but we don't usually block on meta bugs (which bug 820202 is).
Reading the previous comments makes me think we should close this as WONTFIX. Thoughts?
blocking-b2g: --- → koi?
Comment 6•12 years ago
|
||
> koi? since it blocks bug 820202 but we don't usually block on meta bugs
> (which bug 820202 is).
>
> Reading the previous comments makes me think we should close this as
> WONTFIX. Thoughts?
I agree.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Updated•12 years ago
|
blocking-b2g: koi? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•