|Next Milestone||Target Milestone: --- → mozilla12|
|Security Resource||Paul Theriault|
|Securtiy Approved for Beta Launch?:||No|
|Data Flow Diagram:||`|
|Final Security Approval:||no|
- allow web content to dial out
- allow content to mediate incoming calls (accept/reject/merge)
- allow content to query transceiver state
- B2G Meta telephony bug https://bugzilla.mozilla.org/show_bug.cgi?id=699235
- Web Telephony meta bug: https://bugzilla.mozilla.org/show_bug.cgi?id=674726
- Detailed code walkthrough for receive call case: https://wiki.mozilla.org/B2G/Architecture#RIL:_Telephony
Data Flow Diagram
Web Telephony is made up of the following components (from lowest level to highest level)
- rild : the proprietary bit of code that talks to the proprietary modem firmware
- rilproxy : the daemon that proxies messages between rild and Gecko (the b2g process)
- Gecko (the b2g process) : implements the higher-level telephony stack
Note that this review does not include the UI application that actually makes and receives the phone calls (e.g. phone.gaiamobile.org). In the case of Gaia these are reviewed as part of a separate review. Note that a b2g device could ship with a completely different dialer application.
TDB: proper diagram
- Do pages have direct access to the audio streams of a phone call?
- Can another application record audio while a call is underway?
- Not sure, but probably not. Currently no, since no API to access audiostreams.
- Are the audio streams buffered anywhere on disk or is there any local record of the call (if so, what data is stored)?
- Not stored on disk at all. API doesn't store any records, although Gaia app would be expected to do so.
|ID||Title||Threat||Proposed Mitigations||Threat Agent||Rating||Likelihood||Notes||Impact||Notes|
|1||Unauthorized content accesses the Web Telephony API||A web page or web app accesses the Telephony API with having the valid permissions or requirements||
||Malicious web content||?||Requires a bug in broader browser security model||
|2||Attack from radio network||Malicious service provider or attacker with ability to inject radio packets could attack the web telephony stack.||
||Malicious service provider or attacker with ability to inject radio packets||?||?||?|
|3||Bug in Web Telephony stack leads to code execution vulnerability||A web page could supply malicious data to an API, triggering an exploitable crash.||
||Malicious web content||?||
|4||Content spoofing phones dialer app||Webpage or app masquerades as the dialer for a complex phishing attack||
||Malicious web content||?|
|5||Content framing the dialer app||If content could frame the dialer app, or load it in a manner where it was obscured, malicious content might be able to induce the user to make a call.||
||Malicious web content|
|6||Denial of Service on Dialer||
||Malicious web content|
- Implicit: An app which a user wants to act as a dialer will need to be granted the appropriate permissions. Once granted the app will have complete access to this API and be trusted to make and receive phone calls.
Potential Security Features
- Only certified code can be granted this permission.
- Support for a number blacklist? (prevent calls to premium numbers?)
- Rate-limiting? (restrict the number of calls that can be initiated in a certain time period?) Not sure if useful.