Security/Reviews/B2G/NetworkAlerts

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 due to lack of 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.

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

 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

Threat	Description	Mitigation
Base Station compromise	An attacker can set up a compromised base station and send arbitrary cell broadcast messages to connected devices.	Proper input handling, input validation, de-duplication, rate-limiting
Malicious local app	Unauthorized apps could trigger arbitrary alert events and flood the user with alert messages.	Permission model, event filtering

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 o 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 handles 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 arbitrary PWS alerts, resulting in a DoS, 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. This should be fixed ASAP.

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

Malicious local app

generating and receiving 'cellbroadcast-received' events is properly limited to apps with 'cellbroadcast' permission.

in future FxOS versions that are planned to enable IPC via window.open()

Actions & Recommendations

• Implement alert de-duplication for re-broadcasted PWS events.
• Work out architectural change that prevents malicious local apps from sending GET requests to attention.html and notification.html.
  • Message authentication via secret token?
  • Different calling mechanism?

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