CVE-2019-15054 Report

11/16/2019 Author's Note:
As of November 16^th, 2019, CVE-2019-15054 has been patched with the release of Mailbird 2.7.5.0.

Hey Mailbird Team,

I've just started using Mailbird recently, and so far I really like it. It has a really intuitive and beautiful UI.
I'm writing to you because I have discovered a few security vulnerabilities in Mailbird that allow attackers to execute Javascript code contained within a HTML mail message in a privileged context.
The methods by which this can happen are as follows. I've included a proof of concept for each in the attached zip file (password is ██████).

1. An SVG file containing Javascript imported via a <link rel=import. This requires no user interaction to execute code.
2. An SVG file containing Javascript embedded via an embed tag. This requires no user interaction to execute code.
3. Javascript included in an onmousemove attribute. This requires the user to move their mouse over the email body before code is executed.
4. A link to a javascript: URI. This requires the user to click a link before code is executed.
5. A link to a data: URI containing a <script element. This requires the user to click a link before code is executed. (Edit 10/29: Patched)
6. A javascript: URI within an HTML formaction attribute. This requires the user to click a button before code is executed.

To reproduce these issues, load each of the proofs of concept from the attached zip file (password is ██████) into Mailbird as an HTML mail message.
Once a hypothetical attacker has achieved Javascript execution in the user's email client via one of the above vectors, they can:

1. Send any subsequently opened mail message to a server of their choice by hooking the loadHtml function. This access persists until Mailbird is closed.
2. Mount an attack on the renderer (Chromium 51.0.2704.103) using one of 405 vulnerabilities in that version. This would allow arbitrary code execution with the user's login token. (Edit 10/29: Patched)

A demonstration of these capabilities is included in poc-extcap.html, included in the attached zip file.

To fix these vulnerabilities and preempt similar vulnerabilities in the future, I would recommend that the following steps be taken:

1. Update CefSharp (and therefore Cef, and therefore Chromium) to the latest stable version, and keep it updated. Out-of-date Chromium accumulates vulnerabilities very fast; Chrome 74.0.3729.108, released April 2019, already has 15 reported security vulnerabilities. ██████
   ██████████████████████████████████████████████████████████████
   ████ (Edit 10/29: Mostly complete)
2. Implement a whitelist of safe HTML elements, HTML attributes, and URI schemes that cannot possibly execute Javascript and remove any HTML not on the whitelist before rendering an email. This will not cause any degradation to user experience because the set of HTML elements, HTML attributes, and URI schemes appearing in legitimate emails is already bounded. ██████████████████████████████████████████████████████
   (Edit 11/12: Patched using CSP directives)

I will be following the industry standard of responsible disclosure with these vulnerabilities, as elucidated in Google's policy. Your deadline is (August 5 + 90 days = ) November 3rd, 2019.

Please notify me when you have successfully reproduced the bugs using my proofs of concept, or if you have trouble reproducing the vulnerabilities. Additionally, feel free to email me about any other matter in connection with my report; I'm here to help.

Thank you for your time.

Kind regards,
Sam Haskins

Timeline:
(America/Toronto time zone)
July 28^th, 2019: Vulnerability discovered.
August 4^th, 2019: Initial contact made with vendor via support site.
August 5^th, 2019: Report submitted to vendor.
August 6^th, 2019: Contacted by vendor CTO.
August 9-13, 2019: Vulnerability acknowledged by vendor.
August 14^th, 2019: CVE requested; assigned CVE-2019-15054.
October 31^st, 2019: Vendor requested extension of deadline to November 17^th.
November 1^st, 2019: Deadline extension granted.
November 3^rd, 2019: 90 days public disclosure deadline.
November 11^th, 2019: Received patched version from vendor.
November 12^th, 2019: Tested patched version; patch resolves vulnerability.
November 16^th, 2019: Patched version released; report published.