Security/WebAPI/Web Telephony

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Project Info

Web Telephony
Project Page https://wiki.mozilla.org/WebAPI/WebTelephony
Next Milestone Target Milestone: --- → mozilla12
Security Resource Paul Theriault


Security Information

Status: OK
Securtiy Approved for Beta Launch?: No
Data Flow Diagram: `
Threat Model: `
Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=674726
Security Review: `
Final Security Approval: no

Background

Goals

  • allow web content to dial out
  • allow content to mediate incoming calls (accept/reject/merge)
  • allow content to query transceiver state

Bug:

Pages:

Changeset

Source:

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

Webtelephony.png

Answered Questions

  • Do pages have direct access to the audio streams of a phone call?
    • No
  • 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.

Open Questions

Threat Analysis

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
  • App Permissions Model will enforce which apps can access which APIs
  • B2G security model will enforce permissions model at a process level (ie less privileged process not allowed to send IPDL messages even if permissions check fails at an API level)
 Malicious web content ? Requires a bug in broader browser security model
  • Place unauthorized calls, cost the user money, make spam phone calls
  • Use phone a bugging device, breach user privacy
  • probably would have broader implications
2 Attack from radio network Malicious service provider or attacker with ability to inject radio packets could attack the web telephony stack.
  • Code review
  • Fuzzing
 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.
  • Code review
  • Fuzzing
  • Limiting access to API
 Malicious web content ?
  • Dangerous since it involves privileged code
4 Content spoofing phones dialer app Webpage or app masquerades as the dialer for a complex phishing attack
  • Sort of a broader B2G issue (all apps could be spoofed)
  • Only high-privileged content process will have access to send dialer IPDL messages
 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.
  • Broader B2G issue
  • Only high-privileged content process will have access to send dialer IPDL messages
 Malicious web content
6 Denial of Service on Dialer
  • Denial of service, somehow disabling the phone app, or causing it to lose it's permissions?
  • Locking up audio channels, changing mic volume etc to interfere with calls
  • Would probably require permissions to launch these styles of attacks?
 Malicious web content

Authorization Model

  • 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.

Implementation Requirements

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.
Retrieved from "https://wiki.mozilla.org/index.php?title=Security/WebAPI/Web_Telephony&oldid=1020777"