Item Reviewed
| WebSMS | |
| Target | |
{{#set:SecReview name=WebSMS
|SecReview target=
}}
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- allow web platform to send and recieve SMS messages
- for messaging apps
- intended for use in B2G
Links
Main implementation bug: https://bugzilla.mozilla.org/show_bug.cgi?id=674725 DOM API code is here: http://mxr.mozilla.org/mozilla-central/source/dom/sms/ B2G Meta Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=709564 B2g: Pretty complicated, but this page has a good overview of the B2G telephony implementation https://wiki.mozilla.org/B2G/Architecture . See the section called RIL:Telephony. Android: Code is here: http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoSmsManager.java It is using IPC and JNI to go from the DOM API in C++ to the Java backend. SMS are stored in IndexedDB (in B2G) - all of sending and reading done from the web a Radio layer only handles the radio, only way to access SMS database is via WebAPI Web API
Web api contains functions for sending and getting messages from the message database. There are also events to listen for to cover sent, delivered and received events.
- Sending: navigator.mozSms.send(num,msg) or navigator.mozSms.send(num[],msg)
- Events:
- smssent: happens on all window when a SMS is sent;
- smsdelivered: happens on all window when a SMS is delivered to the recipient;
- smsreceived: happens on all window when a SMS is received.
- Get message: navigator.mozSms.getMessage(id)
- Get messages: navigator.mozSms.getMessage(SMSFilter,id)
What solutions/approaches were considered other than the proposed solution?
- N/A, lots of different APIs
Why was this solution chosen?
- did not exist prior to this
Any security threats already considered in the design and why?
- security model = about:config options
- Defaults are off, and blank respectively:
- +pref("dom.sms.enabled", false);
- +pref("dom.sms.whitelist", "");
- Defaults are off, and blank respectively:
- always disabled on android, can be turned on -- but still won't work if the app (Fennec) doesn't have SMS permission on the phone, and it currently doesn't
Threat Brainstorming
- All local files can send recieve and read SMS?
- only on B2G, temporarily
- Sms for 2-factor auth?
- QUESTION - Does this allow webpage content to send an SMS message?
- Current plan is that WebSMS would not be within mobile firefox
- isn't that the point? I guess "apps" aren't necessarily the same as pages.
- Should we prevent non-ssl connections from using this feature?
- Could we enforce HSTS?
- Not sure what validation is done prior to handing messages to radio layer - potential for malformed messages being passed down to radio stack
- Could we enforce HSTS?
- Does IndexedDB (used on B2G) have a similar SQLi-like attack path?
- Should not be a problem. IndexedDB isn't string-based anywhere, so nothing should be injectable to cause things to happen outside of expected boundaries. I.e. we'll just store bobby tables name in the database.
{{#set: SecReview feature goal=* allow web platform to send and recieve SMS messages
- for messaging apps
- intended for use in B2G
Links
Main implementation bug: https://bugzilla.mozilla.org/show_bug.cgi?id=674725 DOM API code is here: http://mxr.mozilla.org/mozilla-central/source/dom/sms/ B2G Meta Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=709564 B2g: Pretty complicated, but this page has a good overview of the B2G telephony implementation https://wiki.mozilla.org/B2G/Architecture . See the section called RIL:Telephony. Android: Code is here: http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoSmsManager.java It is using IPC and JNI to go from the DOM API in C++ to the Java backend. SMS are stored in IndexedDB (in B2G) - all of sending and reading done from the web a Radio layer only handles the radio, only way to access SMS database is via WebAPI Web API
Web api contains functions for sending and getting messages from the message database. There are also events to listen for to cover sent, delivered and received events.
- Sending: navigator.mozSms.send(num,msg) or navigator.mozSms.send(num[],msg)
- Events:
- smssent: happens on all window when a SMS is sent;
- smsdelivered: happens on all window when a SMS is delivered to the recipient;
- smsreceived: happens on all window when a SMS is received.
- Get message: navigator.mozSms.getMessage(id)
- Get messages: navigator.mozSms.getMessage(SMSFilter,id)
|SecReview alt solutions=* N/A, lots of different APIs |SecReview solution chosen=* did not exist prior to this |SecReview threats considered=*security model = about:config options
- Defaults are off, and blank respectively:
- +pref("dom.sms.enabled", false);
- +pref("dom.sms.whitelist", "");
- Defaults are off, and blank respectively:
- always disabled on android, can be turned on -- but still won't work if the app (Fennec) doesn't have SMS permission on the phone, and it currently doesn't
|SecReview threat brainstorming=* All local files can send recieve and read SMS?
- only on B2G, temporarily
- Sms for 2-factor auth?
- QUESTION - Does this allow webpage content to send an SMS message?
- Current plan is that WebSMS would not be within mobile firefox
- isn't that the point? I guess "apps" aren't necessarily the same as pages.
- Should we prevent non-ssl connections from using this feature?
- Could we enforce HSTS?
- Not sure what validation is done prior to handing messages to radio layer - potential for malformed messages being passed down to radio stack
- Could we enforce HSTS?
- Does IndexedDB (used on B2G) have a similar SQLi-like attack path?
- Should not be a problem. IndexedDB isn't string-based anywhere, so nothing should be injectable to cause things to happen outside of expected boundaries. I.e. we'll just store bobby tables name in the database.
}}
Action Items
| Action Item Status | In Progress | |||||||||||||||||||||||||||||||||||||||||||||||||
| Release Target | ` | |||||||||||||||||||||||||||||||||||||||||||||||||
| Action Items | ||||||||||||||||||||||||||||||||||||||||||||||||||
4 Total; 0 Open (0%); 4 Resolved (100%); 0 Verified (0%); |
||||||||||||||||||||||||||||||||||||||||||||||||||
{{#set:|SecReview action item status=In Progress
|Feature version=`
|SecReview action items=
| Who | bug | Action | By When | Completed date |
| ptheriault | bug 741871 | radio testing (test that our implementation conforms to spec) http://www.blackhat.com/presentations/bh-usa-09/MILLER/BHUSA09-Miller-FuzzingPhone-PAPER.pdf | before releasing B2G phone | [NEW] new |
| ptheriault | bug 741872 | audit sqlite interface to ensure parameterized queries and other SQLi defenses (I guess this is just the Fennec version?). | Before enabled on Android | [NEW] new |
| ptheriault | bug 741874 | Look at Gaia code - ensure dialer and sms can't be opened in an iframe maybe? Comes back to permissions model of B2G - gaia sms app author is vingtetun on IRC | before releasing B2G phone | [NEW] new |
| cdiehl | bug 741876 | fuzzing PDU | before releasing B2G phone | [NEW] new |
| ptheriault | develop a list of threats as inputs to permissions model | [DONE] complete 2012-03-20 |
| ID | Summary | Priority | Status |
|---|---|---|---|
| 741871 | [Security Review][Action Item]WebSMS - radio stack testing | -- | RESOLVED |
| 741872 | [Security Review][Action Item]WebSMS - sqlite queries | -- | RESOLVED |
| 741874 | [Security Review][Action Item]WebSMS - gaia code review | -- | RESOLVED |
| 741876 | [Security Review][Action Item]WebSMS - PDU fuzzing | -- | RESOLVED |
4 Total; 0 Open (0%); 4 Resolved (100%); 0 Verified (0%);
}}