Skip to content
This repository has been archived by the owner on Dec 27, 2022. It is now read-only.

Critical security issue [solved in 0.8.9] [CVE-2020-12079] #1519

Closed
imagemlt opened this issue Mar 10, 2020 · 9 comments
Closed

Critical security issue [solved in 0.8.9] [CVE-2020-12079] #1519

imagemlt opened this issue Mar 10, 2020 · 9 comments
Labels
critical CVE Confirmed security issue

Comments

@imagemlt
Copy link

hello, I've find a critical vulnerability inside beaker browser, and have sent you details of this vulnerability by sending email to @pfrazee . Please check it and feel free to contact me.

@imagemlt imagemlt changed the title Security issue report security issue report Mar 10, 2020
@pfrazee
Copy link
Member

pfrazee commented Mar 10, 2020 via email

@pfrazee pfrazee changed the title security issue report Critical security issue [solved in 0.8.9] Mar 13, 2020
@pfrazee
Copy link
Member

pfrazee commented Mar 13, 2020

This issue was confirmed and patched. Anybody currently using Beaker 0.8.x should please update to Beaker 0.8.9 or the latest master if building from source.

I will post a detailed post-mortem on this issue after users have had time to update. Huge thanks to @imagemlt for researching and responsibly disclosing this issue!

@rzelnik
Copy link

rzelnik commented Mar 13, 2020

Snap store still contains 0.8.8 as latest version.
https://snapcraft.io/beaker-browser

@pfrazee
Copy link
Member

pfrazee commented Mar 13, 2020

@rzelnik I've never published the builds anywhere other than on GitHub. Whoever uploads that will need to add the new binary.

@rzelnik
Copy link

rzelnik commented Mar 13, 2020

@pfrazee I will let him know.

@pfrazee
Copy link
Member

pfrazee commented Mar 26, 2020

Post mortem on this issue

First I want to say, thank you so much to @imagemlt for researching and privately disclosing this issue. They were extremely helpful, clear, and generous with their time.

Beaker uses Electron/Chromium's tools to sandbox every tab from the rest of the system. Like other browsers, this sandbox exists at two levels: the Web Platform sandbox which only provides safe APIs, and the process sandbox which restricts any kind of operations if the Web Platform sandbox were penetrated. Web API calls are translated into messages to Beaker's internal processes which then apply permissions and handle their requests.

When a page loads, Beaker use's an Electron feature called the "preload script" to inject its custom Web APIs (e.g. the Hyperdrive API). These APIs are effectively wrappers around inter-process messaging channels. The preload script environment provides Electron APIs for accessing the channels, and then removes those APIs once the page loads.

For added security, Electron provides a "context isolation" flag for the preload script which ensures that the page could never access those messaging-channel-APIs directly. I incorrectly believed that no other messaging channel existed other than the ones documented by those APIs. Therefore I assumed that, even if a page was able to access the Electron APIs exposed in the preload script, it would not be possible to craft a message that could cause an issue -- that it would be similar to using the Web APIs we normally expose. Therefore, I did not enable the context isolation flag.

To be clear: this was a mistake on my part. The Electron team has explicitly advised all developers to use context isolation and I ignored that advice. I apologize for that. I wasn't familiar enough with the internal details of Electron to go against the advice, and that's why this exploit was possible. This was my fault.

It turns out that Electron has its own messaging channel which is not normally accessible, but which can be accessed by polluting the Function prototype chain. @imagemlt was able to use a prototype-pollution attack to access Electron's internal messaging API. They then spawned a new page with all of the web-platform protections disabled, which enabled them to freely exit the sandbox -- which they proved by spawning calculator.app.

Solving this was straight-forward: I turned on context isolation and then used Electron's contextBridge API to safely expose our Web APIs to the page. This makes a prototype-pollution attack infeasible, and closes the security hole.

Be sure to use only Beaker 0.8.9 and above to stay protected from this attack.

Going forward, I will be checking and rechecking Beaker against Electron's security guidelines. I also intend to learn about Electron's internal messaging channel and investigate whether my original assumption -- that no dangerous messages can be constructed -- can be made true.

Thanks again to @imagemlt for responsibly disclosing this issue, and also to the Electron team for the excellent tools and guidance they provide for security. If anybody has any followup questions or concerns, feel free to ask them here or by email.

@imagemlt
Copy link
Author

would you mind me request a CVE ID for this? https://cve.mitre.org/

@pfrazee
Copy link
Member

pfrazee commented Mar 31, 2020

@imagemlt Sure thing. I'll need a little time to fulfill their requirements, so I'll keep you updated on the progress

@pfrazee pfrazee added the CVE Confirmed security issue label Apr 28, 2020
@pfrazee pfrazee changed the title Critical security issue [solved in 0.8.9] Critical security issue [solved in 0.8.9] [CVE-2020-12079] Apr 28, 2020
@pfrazee
Copy link
Member

pfrazee commented Apr 28, 2020

We've assigned a CVE to this issue:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12079

Closing now as this is handled. Thanks again, @imagemlt !

@pfrazee pfrazee closed this as completed Apr 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
critical CVE Confirmed security issue
Projects
None yet
Development

No branches or pull requests

3 participants