How did an Electron framework flaw put Slack at risk?

An Electron framework flaw put major apps like Slack at risk of remote code execution. What is the flaw and what should be done to safeguard apps from similar vulnerabilities?

The Electron framework enables developers to write a cross-platform desktop application using JavaScript, HTML and CSS, thus avoiding the need to create it multiple times in different languages for multiple platforms. It is based on Node.js and Chromium and is used by more than 460 cross-platform desktop applications, including many popular apps such as WordPress, Skype, Slack and others.

A recently discovered remote code execution Electron framework flaw has put all these apps' users at risk. It's another example of how a flaw in a popular development framework can affect hundreds of apps and millions of users because the flaw is inherited by any code developed using the framework.

In the case of this particular Electron framework flaw, macOS and Linux systems aren't vulnerable, but Electron-based apps that are built for Windows and that register themselves as the default handler for a protocol are.

To make it possible for users to click links in one program and open the content in another, Electron provides the ability to register a protocol handler to automate the whole process. So, for example, clicking on a link beginning slack:// in a web browser will open the Slack app, while exodus:// will open the Exodus desktop multi-asset wallet. Unfortunately, this convenient functionality also enables an attacker to create a malicious link to an Electron-based app that will execute whatever command the attacker wants to run.

Any Electron apps that run on Windows 7, 10 or 2008 and that register custom protocol handlers can be tricked into arbitrary command execution if a user is socially engineered into clicking on a specially crafted URL, making this a dangerous security flaw. Assigned the CVE identifier CVE-2018-1000006, the Electron framework flaw occurred due to a lack of validation and sanity checks on any arguments passed to the app via the uniform resource identifier handler. This enables an attacker to execute various Chromium command-line switches, like using gpu-launcher to spawn a new process.

Developers using third-party frameworks, modules, libraries and open source code, which is nearly everyone, must ensure that they know how to keep these libraries and frameworks up to date and follow news feeds and mailing lists to ensure they stay abreast of any security warnings that are issued. Products such as WhiteSource and Black Duck Software can also be used to track and manage security issues in open source code.

Developers should also be aware of and understand any security guidelines provided with third-party code to ensure that they are implementing its features safely. For example, Electron provides a comprehensive checklist of security recommendations that stress the point that displaying arbitrary content from untrusted sources poses a severe security risk, and that if an application does execute code from an online source, it is the developer's responsibility to ensure that the code is not malicious.

Undertaking at least a quarterly audit will catch any code sources that are not up to date and ensure that there are no outstanding security issues. The development lifecycle should include a tried and tested process to patch application code as soon as possible should a critical situation arise and push the necessary updates out to users.

Ask the expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)