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.
Component: DOM: Device Interfaces → DOM: Apps
OS: Mac OS X → All
Hardware: x86 → All
Component: DOM: Apps → General
Product: Core → Boot2Gecko
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..
Is this necessary for v1? If so, please nominate for b-b?
Actually on reflection, and further understanding of activities, all of these actually just result in a web activity. 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?  http://dxr.mozilla.org/mozilla-central/b2g/chrome/content/shell.js.html#l511
blocking-basecamp: --- → ?
Flags: needinfo? → needinfo?(fabrice)
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.
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?
> 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
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.