Security/Reviews/Gaia/system

App Review Details

• App: System App
• Review Date: 7 March 2013
• Review Lead: Paul Theriault

Overview

At the heart of Gaia is the System App which is the app which loads all other apps, and takes care manages all system level activities. When B2G starts, system app is loaded, which loads scripts providing the the interface for the phone, including the home screen, lock screen, status bar and various other components. The system app manages running applicaitons, and provides system level UI, such as notifications, the lockscreen, status bar, popups/dialogs amongst other things. Applications are loaded into iframes within the system (of type mozapp and mozbrowser, so that the system app can monitor events and manage them).

Once loaded, the simplified window hierarchy is as follows: <window>Gecko Chrome

  |
  +--> <iframe> system app
          |
          +--> <iframe> homescreen app
          |
          +--> <iframe> keyboard
          |
          +--> <iframe> lockscreen
          |
          +--> ... more app iframes are created here as apps are loaded

Architecture

Inputs/Outputs

• chromeEvent & customEvent interface
  • Todo: how does gecko validate the sender of customEvents ? Is it ever possible that a customEvent sent from another app might end up received by gecko? I guess not because of the window hierarchy but I am not sure of this.

• system messages

One way messaging from gecko to apps. App can declare that they want to receive certain messages, and if they have the right permissions they will be sent these messages (handled by navigator.setMessageHandler(topic,…)

• mozBrowser events

Components

The system is made up of many different parts, but the main ones are:

• Lockscreen: shown when the phone is first turned on. Includes and camera and dialer for use when the phone is locked (since apps can't be launched when the phone is locked).

• Attention screen: an overlay window in which apps with the 'attention' permission can show content (its the only way for a background app to show content). Used for thing like displaying the incoming call screen etc.

• CardsView: This is the main UI handling component - apps are loaded into 'cards' which are shown and hidden as the user lauches and switches apps.

• identitiy.js: persona integration for firefox OS

• payment.js: provide UI and mechanism to integrate with the Payments API

• Keyboard manager: loads the keyboard

• Widgets and dialogs to handle all system UI events

• Utility (notification) tray: shown notifications when the drags the top bar down

• Top bar: shows important information like mobile connection status, API use indicators (geological etc)

• Update manager: manages downloading an installing updates

Relevant Source Code

See Security/Reviews/Gaia/system/code

Permissions

Unsurprisingly the system has most permissions:

permissions": {
11     "alarms": {},
12     "browser":{},
13     "power":{},
14     "fmradio":{},
15     "webapps-manage":{},
16     "mobileconnection":{},
17     "bluetooth":{},
18     "telephony":{},
19     "voicemail":{},
20     "device-storage:sdcard":{ "access": "readonly" },
21     "device-storage:pictures":{ "access": "readwrite" },
22     "device-storage:videos":{ "access": "readwrite" },
23     "device-storage:music":{ "access": "readcreate" },
24     "settings":{ "access": "readwrite" },
25     "storage":{},
26     "camera":{},
27     "geolocation":{},
28     "wifi-manage":{},
29     "desktop-notification":{},
30     "idle":{},
31     "network-events":{},
32     "embed-apps":{},
33     "background-sensors":{},
34     "permissions":{},
35     "audio-channel-notification":{},
36     "audio-channel-content":{},
37     "cellbroadcast":{},
38     "keyboard":{}
39   }

One notable permission tht only the system app has is embed-apps. Only the system app has the power to launch an app. (ie. <iframe mozapp> doesnt work unless you have this permission)

Web Activity Handlers

The system app doesn't handle any web activities (though it does provide some of the glue which makes web activities work - for example the UI where the user chooses which app will handle an activity is in the system app)

Web Activity Usage

The system app make use of some web activities, mainly to start other apps: mxr search . onSuccess and return values are not used very much so there isn't much of a threat vector here (the ones that do, can't really be affected by spoofed values etc)

Code Review Notes

1. XSS & HTML Injection attacks

Dynamic HTML is used extensively:

• execution sinks [-]
  • setTimeout (97)
  • setInterval (4)
• HTMLElement sinks [-]
  • .innerHTML (34)
  • .outerHTML (5)
• URL sinks [-]
  • \.src (40)
  • \.data (244)
  • \.href (5)
  • \.action (5)

Reviewing these items, and others did not reveal any HTML/script injection issues however.

Like other apps, this app could benefit from removal of potential dangerous patterns like combining strings and assigning them to HTML: http://mxr.mozilla.org/gaia/source/apps/system/js/cards_view.js#250

Even though no issues are currently seen, replacing innerHTML with createElement/setAttribute would remove the risk of injection in the future. (as would the application of a CSP).

2. Secure Communications

The system app doesnt load any remote code in its own process.

5. Use of Privileged APIs

The system app needs most privileges since it acts as the gateway between apps and gecko. Notably it has camera and telephony permissions in order to provide that function prior to the lockscreen. In the long term, it may be better to have these as seperate apps, although ultimately, the system app has the permission to change app permissions (including its own)

6. Interfaces with other Apps/Content

See code review section for detailed analysis

Security Risks & Mitigating Controls

• See the code review section above.

Actions & Recommendations

1. Remove source-view from system app
2. Geolocation prompt for system app is confusing and shown only after the phone is unlocked
3. bug 850554
4. bug 854849