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?
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.)
Dig Deeper on Application attacks (buffer overflows, cross-site scripting)
Related Q&A from Michael Cobb
Sending sensitive information in attachments is inherently unsafe, and the main way to secure them -- encryption -- can be implemented inconsistently... Continue Reading
Spyware can steal mundane information, track a user's every move and everything in between. Read up on the types of spyware and how to best fix ... Continue Reading
Explore the differences between symmetric vs. asymmetric encryption algorithms, including common uses and examples of both, as well as their pros and... Continue Reading