From MozillaWiki
< Security‎ | Reviews‎ | Gaia
Jump to: navigation, search

App Review Details




The app is using multiple stages of workers to achieve responsiveness. To quoting from the main-frame-setup.js file:

  • Main: Initializes worker support logic
  • Main: Spawns worker
  • Worker: Loads core JS
  • Worker: 'hello' => main
  • Main: 'hello' => worker with online status and mozAlarms status
  • Worker: Creates MailUniverse
  • Worker 'mailbridge'.'hello' => main
  • Main: Creates MailAPI, sends event to UI
  • UI: can really do stuff

Relevant Source Code

Despite the email folder in main gaia repo, there's also a repo for the required and used libraries


Permissions advertised in the manifest are

  • alarms: for regular email synchronization
  • audio-channel-notification: to make the phone beep :)
  • contacts: to get email addresses to send to and create contacts one received from
  • notifications: to notify the user of new emails
  • storage: to store attachments on the devices
  • systemXHR: to make outgoing HTTP calls for (among others) the ISPDB and ActiveSync. (NB The ISPDB might be removed/downgraded to anonymous CORS XHR in the future, once the ISPDB supports CORS. See bug 901540)
  • settings: this mostly reads settings, for language, date/time, notification and audio settings
  • tcp-socket: for IMAP/SMTP connections

These are the last permissions the app requires to work properly with the current permission model.

Web Activity Handlers

Web Activity Usage

Notable Event Handlers

Code Review Notes

1. XSS & HTML Injection attacks

  • The amount of innerHTML assignments has been reduced to near minimum (see bug 901470. The most critical part remains the sanitizer for HTML emails, which has been tested to a great detail in bug 783958.

2. Secure Communications

  • The app uses SSL/TLS for IMAP and SMTP by default! :)

3. Secure data storage

  • Data is stored using IndexedDB, Settings (account data?), and the filesystem (attachments)

4. Denial of Service

  • The parsing bits are making too hopeful assumptions on strings in emails, which can cause Exceptions that are not being caught, e.g. bug 901926

5. Use of Privileged APIs

The main problem with reviewing these APIs is that most of them are used through several layers of indirection, this is tu facilitate the use of workers within the app. The email has a very generic sendMessage function that handles most internal notification. This involves the main message handler having access to sockets and other valuable APIs that might be called depending on the message content. Malicious user input in sendMessage calls may cause the email app to behave in an unexpected way. This also means that most API names are just in the message handler but may be triggered from various parts of the application.


  • This is being used for the SMTP/IMAP client and abstracted into a socket object in ./js/ext/mailapi/main-frame-setup.js..

mozSetMessageHandler (Activities)

  • This is used to catch mailto URLs.


  • This is used to schedule regular email synchronization (see worker-bootstrap.js, function _scheduleNextSync)

6. Interfaces with other Apps/Content

Security Risks & Mitigating Controls

HTML Injections / Sanitization

The biggest security risk is the custom HTML sanitization part. It has been tested in great detail using a custom setup explained in bug 783958. The sanitization part is using bleach that is being called in mailchew. Sanitization happens when a message's content is received or a reply is being prepared. When a new email is being processed (function processMessageContent) sanitizeAndNormalizeHtml and generateSnippet are being called. The former is to sanitize the message (it is being stored that way, so we only call the comparably expensive sanitizer once) and generate a non-HTML text snippet to show in the inbox overview. If you hit reply, the email app will quote the prior email which requires to generate a text/HTML representation that is safe to include. This happens in generateReplyBody that uses the wrapTextIntoSafeHTMLString function.

Actions & Recommendations

The HTML sanitizer has some outstanding issues:

The email app unnecessarily has access to all system settings. This is an issue with the Settings API that should be improved in a future version of Firefox OS:

  • bug 841071 Settings are globally shared between applications

The HTML sanitizers could need some random/exhaustive fuzzing attention.