Security/Reviews/Gaia/email
Contents
App Review Details
- App: E-Mail
- Review Date: 2013-07-26-2013-08-08
- Review Lead: Frederik Braun
- Review Bug: main review bug, review of the HTML sanitizer
Overview
Architecture
Components
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
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.
mozTCPSocket
- 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.
mozAlarm
- This is used to schedule regular email synchronization (see worker-bootstrap.js, function _scheduleNextSync)
6. Interfaces with other Apps/Content
- window.open and Activities see also bug 902381
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.
