Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Critical security issue [solved in 0.8.9] #1519
Thank you for filing, I’ve received your email. I’ll look into this today.…
On Mar 10, 2020, at 3:47 AM, Image ***@***.***> wrote: 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
This issue was confirmed and patched. Anybody currently using Beaker 0.8.x should please update to Beaker 0.8.9 or the latest
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!
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
Solving this was straight-forward: I turned on context isolation and then used Electron's
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.