Overview

Firefox Accounts Review Details

• Scope: Timeboxed review of Network Alerts for Firefox OS
• Review Date: 2014-09-12
• Review Lead: Christiane Ruetten, cr@mozilla.com

Documentation

• ETSI Technical realization of Cell Broadcast Service (CBS)
• UI flow design

Context

Network Alerts is an implementation of a subset of the ETSI Pulic Warning System (PWS) for Firefox OS 2.1. The PWS standard uses a mobile network's Cell Broadcast Service (CBS) to alert mobile phone users, located in a certain area, to civil or national threats or emergencies, for example earthquakes, tornadoes, and the US-specific AMBER Alerts in case of child abduction.

PWS supports multiple message identifiers which map to the various international alert providers and message types, of which Firefox OS's Network Alerts supports only a subset. Some regulations require mobile endpoints to support relevant national PWS channels.

Upon reception of a CBS message, a mobile device is to determine the alert type, and in case of a PWS message, to display the alert's content in a popup fashion that does not require user interaction.

Scope

Network Alerts consists of a Gaia component handling user interaction and modifications to the Gonk code that interfaces the RIL layer — where cell broadcasts enter the system — with the Gaia world.

The following components were reviewed:

• Network Alerts Gaia app
• PWS-related code in System notification handling
• Changes to System Messages permission handling
• PWS-related changes in the Gonk RIL helper

The following components were not reviewed:

• PWS-handling inside the RIL daemon due to lack of source code
• Settings changes
• Tests

Relevant Source Code

Gaia

• https://mxr.mozilla.org/gaia/source/apps/network-alerts/
• https://mxr.mozilla.org/gaia/source/apps/system/js/notifications.js
• https://mxr.mozilla.org/gaia/source/apps/system/test/unit/notifications_test.js

Gonk

• https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js
• https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js
• https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/RILContentHelper.js

Other

• https://mxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessagePermissionsChecker.jsm

Architecture

RIL is the single source of data for alert messages. It triggers cellbroadcast-received system messages which contain type and body of the broadcast received. Network Alerts registers a onCellbroadcast() event listener, filters for relevant message types and then displays a popup attention message containing only the cellbroadcast message body as external variable content. The message title is the result of a l10 translation of a static string.

In parallel, it opens a new Notification() in the notification tray which generates a 'notification' system message when selected when selected. 'notification' messages are handled by a listener which also opens the attention message.

attention.html and notification.html are called with window.open() calls. Message body and title (which is static) are securely encoded using .encodeURIComponent().

Data Flow

Data in Network Alerts originates solely from the RIL layer via 'cellbroadcast-received' system messages. The data sinks are attention.html, which receives the broadcast message body through a .textContent operation, and a Notification object which is deemed safe handling untrusted data.

Permission Model

The app manifest defines a certified app running in the system role. Four permissions are requested: attention, desktop-notification, cellbroadcast and readonly settings access. The manifest also registers system message handlers for cellbroadcast-received and notification. All permissions are required for proper function and used properly.

 1 {
 2   "name": "Network Alerts",
 3   "description": "Handling network alerts (like CMAS)",
 4   "type": "certified",
 5   "launch_path": "/index.html",
 6   "role": "system",
 7   "developer": {
 8     "name": "The Gaia Team",
 9     "url": "https://github.com/mozilla-b2g/gaia"
10   },
11   "icons": {
12     "30": "/style/icons/icon-30.png",
13     "45": "/style/icons/icon-45.png",
14     "60": "/style/icons/icon-60.png",
15     "68": "/style/icons/icon-68.png"
16   },
17   "permissions": {
18     "attention":{},
19     "desktop-notification":{},
20     "cellbroadcast":{},
21     "settings":{ "access": "readonly" }
22   },
23   "default_locale": "en-US",
24   "orientation": "default",
25   "messages": [
26      { "notification": "/notification.html" },
27      { "cellbroadcast-received": "/index.html"}
28   ]
29 }

Risks and Mitigations

Threat Model overview

Base Station compromise

Mobile networks lack network authentication. Therefore, anyone can set up a BTS, set the MCC/MNC tuple of the poplular local provider, and wait for victims to connect, effectively conducting a MITM attack. This is especially easy for pure GSM networks, and that is sufficient for treating victims with arbitrary PWS broadcast messages. The victim has no way of detecting the attack until it's far too late. Consequently, any PWS message originating from the RIL layer should be treated as potentially containing malicious data.

PWS messages may contain several hundred bytes of arbitrary message data bytes and thus pose a risk for code injection. The current Network Alerts implementation lacks input validation, but the message body data is handled securely. When used for URLs in attention.js and notification.js, it's passed to encodeURIComponent(). When sinked to attention.html, attention.js properly uses .textContent. The Notification framework – the other sink for the message body data – is known to be safe as well. The serviceId used in index.js as array index, potentially resulting in out-of-bounds access, can not be controlled by an attacker.

Message flooding

Not only an attacker can flood victims with PWS alerts resulting in a DoS, but low-frequency message re-broadcasting is the obvious way PWS systems are operated to catch mobile devices that are temporarily out of range or offline. Therefore, the ETSI PWS specification section 8.2 requires mobile devices to perform duplication detection on PWS messages and only display identical messages once every 24 hours, and only once every hour when the MCC is Japan.

However, we could not find duplication detection code in the current Network Alerts implementation, and most likely the RIL layer will not provide it either (we did not verify this). As a result, we assume that Firefox OS users will be subject to "naturally" occurring message flooding in regular PWS systems. While user impact can not be classified security-critical and will be annoying at worst, this should be fixed ASAP.

To further mitigate DoS attacks through BTS compromise, an additional, reasonably high rate-limit for accepting new alert messages would be an option.

Malicious local app

The powerful attention system implemented in Network Alerts can be distracting and annoying for the user when abused. Therefore it must be secured against unauthorized access by local apps. Not only might they be able to inject malicious code in message bodies, but they could also misuse the invasive attention mechanism for their own push messages.

cellbroadcast-received events are properly limited by SystemMessagePermissionsChecker.jsm to apps with cellbroadcast permission which is currently limited to certified apps only. Special attention should be paid when reviewing certified apps that are granted this permission.

The System Messages cell-broadcast and notification can be considered safe as long as they aren't exposed to privileged or even web apps. We strongly advise against exposing cell-broadcast privilege to any other than certified apps in the future.

Within the Network Alerts app, alerts are triggered via window.open(). This is not an issue as long as these URIs can not by called by other local apps. However, there are plans to lift that restriction in future versions of Firefox OS. In this case, the security model of the app must be revisited. An option would be to authenticate calls with a randomized token.

Actions & Recommendations

• Implement alert de-duplication for re-broadcasted PWS events.
• Pay special attention to use of cellbroadcast permission (currently restricted to certified apps).
• Revisit security model when cellbroadcast or notification permissions are enabled for privileged or even exposed to web apps.

Bugzilla references

• Bug 1067295 - Network Alerts security review for the FxOS 2.1 release
• Bug 1026685 - (cmas-application) CMAS Alert channel support
• Bug 1055994 - Fire system message for cell broadcast
• Bug 1067938 - Network Alerts should de-duplicate PWS cell-broadcasts