10 posts tagged with "Security"

Earlier today, the Electron team was alerted to several public CVEs recently filed against several notable Electron apps. The CVEs are related to two of Electron’s fuses - runAsNode and enableNodeCliInspectArguments - and incorrectly claim that a remote attacker is able to execute arbitrary code via these components if they have not been actively disabled.

We do not believe that these CVEs were filed in good faith. First of all, the statement is incorrect - the configuration does not enable remote code execution. Secondly, companies called out in these CVEs have not been notified despite having bug bounty programs. Lastly, while we do believe that disabling the components in question enhances app security, we do not believe that the CVEs have been filed with the correct severity. “Critical” is reserved for issues of the highest danger, which is certainly not the case here.

Anyone is able to request a CVE. While this is good for the overall health of the software industry, “farming CVEs” to bolster the reputation of a single security researcher is not helpful.

That said, we understand that the mere existence of a CVE with the scary critical severity might lead to end user confusion, so as a project, we’d like to offer guidance and assistance in dealing with the issue.

How might this impact me?​

After reviewing the CVEs, the Electron team believes that these CVEs are not critical.

An attacker needs to already be able to execute arbitrary commands on the machine, either by having physical access to the hardware or by having achieved full remote code execution. This bears repeating: The vulnerability described requires an attacker to already have access to the attacked system.

Chrome, for example, does not consider physically-local attacks in their threat model:

We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your device as you, or who can run software with the privileges of your operating system user account. Such an attacker can modify executables and DLLs, change environment variables like PATH, change configuration files, read any data your user account owns, email it to themselves, and so on. Such an attacker has total control over your device, and nothing Chrome can do would provide a serious guarantee of defense. This problem is not special to Chrome ­— all applications must trust the physically-local user.

The exploit described in the CVEs allows an attacker to then use the impacted app as a generic Node.js process with inherited TCC permissions. So if the app, for example, has been granted access to the address book, the attacker can run the app as Node.js and execute arbitrary code which will inherit that address book access. This is commonly known as a “living off the land” attack. Attackers usually use PowerShell, Bash, or similar tools to run arbitrary code.

Am I impacted?​

By default, all released versions of Electron have the runAsNode and enableNodeCliInspectArguments features enabled. If you have not turned them off as described in the Electron Fuses documentation, your app is equally vulnerable to being used as a “living off the land” attack. Again, we need to stress that an attacker needs to already be able to execute code and programs on the victim’s machine.

Mitigation​

The easiest way to mitigate this issue is to disable the runAsNode fuse within your Electron app. The runAsNode fuse toggles whether the ELECTRON_RUN_AS_NODE environment variable is respected or not. Please see the Electron Fuses documentation for information on how to toggle theses fuses.

Please note that if this fuse is disabled, then process.fork in the main process will not function as expected as it depends on this environment variable to function. Instead, we recommend that you use Utility Processes, which work for many use cases where you need a standalone Node.js process (like a Sqlite server process or similar scenarios).

You can find more info about security best practices we recommend for Electron apps in our Security Checklist.

It’s been more than a week since CVE-2023-4863: Heap buffer overflow in WebP was made public, leading to a flurry of new releases of software rendering webp images: macOS, iOS, Chrome, Firefox, and various Linux distributions all received updates. This followed investigations by Citizen Lab, discovering that an iPhone used by a “Washington DC-based civil society organization” was under attack using a zero-click exploit within iMessage.

Electron, too, spun into action and released new versions the same day: If your app renders any user-provided content, you should update your version of Electron - v27.0.0-beta.2, v26.2.1, v25.8.1, v24.8.3, and v22.3.24 all contain a fixed version of libwebp, the library responsible for rendering webp images.

Now that we are all freshly aware that an interaction as innocent as “rendering an image” is a potentially dangerous activity, we want to use this opportunity to remind everyone that Electron comes with a process sandbox that will limit the blast radius of the next big attack — whatever it may be.

The sandbox was available ever since Electron v1 and enabled by default in v20, but we know that many apps (especially those that have been around for a while) may have a sandbox: false somewhere in their code – or a nodeIntegration: true, which equally disables the sandbox when there is no explicit sandbox setting. That’s understandable: If you’ve been with us for a long time, you probably enjoyed the power of throwing a require("child_process") or require("fs") into the same code that runs your HTML/CSS.

Before we talk about how you migrate to the sandbox, let’s first discuss why you want it.

The sandbox puts a hard cage around all renderer processes, ensuring that no matter what happens inside, code is executed inside a restricted environment. As a concept, it's a lot older than Chromium, and provided as a feature by all major operating systems. Electron's and Chromium's sandbox build on top of these system features. Even if you never display user-generated content, you should consider the possibility that your renderer might get compromised: Scenarios as sophisticated as supply chain attacks and as simple as little bugs can lead to your renderer doing things you didn't fully intend for it to do.

The sandbox makes that scenario a lot less scary: A process inside gets to freely use CPU cycles and memory — that’s it. Processes cannot write to disk or display their own windows. In the case of our libwep bug, the sandbox makes sure that an attacker cannot install or run malware. In fact, in the case of the original Pegasus attack on the employee’s iPhone, the attack specifically targeted a non-sandboxed image process to gain access to the phone, first breaking out of the boundaries of the normally sandboxed iMessage. When a CVE like the one in this example is announced, you still have to upgrade your Electron apps to a secure version — but in the meantime, the amount of damage an attacker can do is limited dramatically.

Migrating a vanilla Electron application from sandbox: false to sandbox: true is an undertaking. I know, because even though I have personally written the first draft of the Electron Security Guidelines, I have not managed to migrate one of my own apps to use it. That changed this weekend, and I recommend that you change it, too.

There are two things you need to tackle:

1. If you’re using Node.js code in either preload scripts or the actual WebContents, you need to move all that Node.js interaction to the main process (or, if you are fancy, a utility process). Given how powerful renderers have become, chances are high that the vast majority of your code doesn’t really need refactoring.

   Consult our documentation on Inter-Process Communication. In my case, I moved a lot of code and wrapped it in ipcRenderer.invoke() and ipcMain.handle(), but the process was straightforward and quickly done. Be a little mindful of your APIs here - if you build an API called executeCodeAsRoot(code), the sandbox won't protect your users much.

2. Since enabling the sandbox disables Node.js integration in your preload scripts, you can no longer use require("../my-script"). In other words, your preload script needs to be a single file.

   There are multiple ways to do that: Webpack, esbuild, parcel, and rollup will all get the job done. I used Electron Forge’s excellent Webpack plugin, users of the equally popular electron-builder can use electron-webpack.

All in all, the entire process took me around four days — and that includes a lot of scratching my head at how to wrangle Webpack’s massive power, since I decided to use the opportunity to refactor my code in plenty of other ways, too.

A High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.

This vulnerability has been assigned CVE-2019-13720. You can read more about it in the Chrome Blog Post.

Please note that Chrome has reports of this vulnerability being used in the wild so it is strongly recommended you upgrade Electron as soon as possible.

Scope​

This affects any Electron application that may run third-party or untrusted JavaScript.

Mitigation​

Affected apps should upgrade to a patched version of Electron.

We've published new versions of Electron which include fixes for this vulnerability:

• 6.1.4

Electron 7.0.1 automatically included the fix from upstream, before the announcement was made. Electron 8 is similarly unaffected. The vulnerability did not exist in Electron 5, so that version is also unaffected.

Further Information​

This vulnerability was discovered by Anton Ivanov and Alexey Kulaev at Kaspersky Labs and reported to the Chrome team. The Chrome blog post can be found here.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

A High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.

This vulnerability has been assigned CVE-2019-5786. You can read more about it in the Chrome Blog Post.

Please note that Chrome has reports of this vulnerability being used in the wild so it is strongly recommended you upgrade Electron ASAP.

Scope​

This affects any Electron application that may run third-party or untrusted JavaScript.

Mitigation​

Affected apps should upgrade to a patched version of Electron.

We've published new versions of Electron which include fixes for this vulnerability:

• 4.0.8
• 3.1.6
• 3.0.16
• 2.0.18

The latest beta of Electron 5 was tracking Chromium 73 and therefore is already patched:

• 5.0.0-beta.5

Further Information​

This vulnerability was discovered by Clement Lecigne of Google's Threat Analysis Group and reported to the Chrome team. The Chrome blog post can be found here.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

A code vulnerability has been discovered that allows Node to be re-enabled in child windows.

Opening a BrowserView with sandbox: true or nativeWindowOpen: true and nodeIntegration: false results in a webContents where window.open can be called and the newly opened child window will have nodeIntegration enabled. This vulnerability affects all supported versions of Electron.

Mitigation​

We've published new versions of Electron which include fixes for this vulnerability: 2.0.17, 3.0.15, 3.1.3, 4.0.4, and 5.0.0-beta.2. We encourage all Electron developers to update their apps to the latest stable version immediately.

If for some reason you are unable to upgrade your Electron version, you can mitigate this issue by disabling all child web contents:

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

Further Information​

This vulnerability was found and reported responsibly to the Electron project by PalmerAL.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

A remote code execution vulnerability, "Magellan," has been discovered affecting software based on SQLite or Chromium, including all versions of Electron.

Scope​

Electron applications using Web SQL are impacted.

Mitigation​

Affected apps should stop using Web SQL or upgrade to a patched version of Electron.

We've published new versions of Electron which include fixes for this vulnerability:

• 4.0.0-beta.11
• 3.1.0-beta.4
• 3.0.13
• 2.0.16

There are no reports of this in the wild; however, affected applications are urged to mitigate.

Further Information​

This vulnerability was discovered by the Tencent Blade team, who have published a blog post that discusses the vulnerability.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

A remote code execution vulnerability has been discovered affecting apps with the ability to open nested child windows on Electron versions (3.0.0-beta.6, 2.0.7, 1.8.7, and 1.7.15). This vulnerability has been assigned the CVE identifier CVE-2018-15685.

Affected Platforms​

You are impacted if:

1. You embed any remote user content, even in a sandbox
2. You accept user input with any XSS vulnerabilities

Details

You are impacted if any user code runs inside an iframe / can create an iframe. Given the possibility of an XSS vulnerability it can be assumed that most apps are vulnerable to this case.

You are also impacted if you open any of your windows with the nativeWindowOpen: true or sandbox: true option. Although this vulnerability also requires an XSS vulnerability to exist in your app, you should still apply one of the mitigations below if you use either of these options.

Mitigation​

We've published new versions of Electron which include fixes for this vulnerability: 3.0.0-beta.7, 2.0.8, 1.8.8, and 1.7.16. We urge all Electron developers to update their apps to the latest stable version immediately.

If for some reason you are unable to upgrade your Electron version, you can protect your app by blanket-calling event.preventDefault() on the new-window event for all webContents'. If you don't use window.open or any child windows at all then this is also a valid mitigation for your app.

mainWindow.webContents.on('new-window', (e) => e.preventDefault());

If you rely on the ability of your child windows to make grandchild windows, then a third mitigation strategy is to use the following code on your top level window:

const enforceInheritance = (topWebContents) => {
  const handle = (webContents) => {
    webContents.on(
      'new-window',
      (event, url, frameName, disposition, options) => {
        if (!options.webPreferences) {
          options.webPreferences = {};
        }
        Object.assign(
          options.webPreferences,
          topWebContents.getLastWebPreferences()
        );
        if (options.webContents) {
          handle(options.webContents);
        }
      }
    );
  };
  handle(topWebContents);
};

enforceInheritance(mainWindow.webContents);

This code will manually enforce that the top level windows webPreferences is manually applied to all child windows infinitely deep.

Further Information​

This vulnerability was found and reported responsibly to the Electron project by Matt Austin of Contrast Security.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

A vulnerability has been discovered which allows Node.js integration to be re-enabled in some Electron applications that disable it. This vulnerability has been assigned the CVE identifier CVE-2018-1000136.

Affected Applications​

An application is affected if all of the following are true:

1. Runs on Electron 1.7, 1.8, or a 2.0.0-beta
2. Allows execution of arbitrary remote code
3. Disables Node.js integration
4. Does not explicitly declare webviewTag: false in its webPreferences
5. Does not enable the nativeWindowOption option
6. Does not intercept new-window events and manually override event.newGuest without using the supplied options tag

Although this appears to be a minority of Electron applicatons, we encourage all applications to be upgraded as a precaution.

Mitigation​

This vulnerability is fixed in today's 1.7.13, 1.8.4, and 2.0.0-beta.5 releases.

Developers who are unable to upgrade their application's Electron version can mitigate the vulnerability with the following code:

app.on('web-contents-created', (event, win) => {
  win.on(
    'new-window',
    (event, newURL, frameName, disposition, options, additionalFeatures) => {
      if (!options.webPreferences) options.webPreferences = {};
      options.webPreferences.nodeIntegration = false;
      options.webPreferences.nodeIntegrationInWorker = false;
      options.webPreferences.webviewTag = false;
      delete options.webPreferences.preload;
    }
  );
});

// and *IF* you don't use WebViews at all,
// you might also want
app.on('web-contents-created', (event, win) => {
  win.on('will-attach-webview', (event, webPreferences, params) => {
    event.preventDefault();
  });
});

Further Information​

This vulnerability was found and reported responsibly to the Electron project by Brendan Scarvell of Trustwave SpiderLabs.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

To report a vulnerability in Electron, please email security@electronjs.org.

Please join our email list to receive updates about releases and security updates.

A remote code execution vulnerability has been discovered affecting Electron apps that use custom protocol handlers. This vulnerability has been assigned the CVE identifier CVE-2018-1000006.

Affected Platforms​

Electron apps designed to run on Windows that register themselves as the default handler for a protocol, like myapp://, are vulnerable.

Such apps can be affected regardless of how the protocol is registered, e.g. using native code, the Windows registry, or Electron's app.setAsDefaultProtocolClient API.

macOS and Linux are not vulnerable to this issue.

Mitigation​

We've published new versions of Electron which include fixes for this vulnerability: 1.8.2-beta.5, 1.7.12, and 1.6.17. We urge all Electron developers to update their apps to the latest stable version immediately.

If for some reason you are unable to upgrade your Electron version, you can append -- as the last argument when calling app.setAsDefaultProtocolClient, which prevents Chromium from parsing further options. The double dash -- signifies the end of command options, after which only positional parameters are accepted.

app.setAsDefaultProtocolClient(protocol, process.execPath, [
  '--your-switches-here',
  '--',
]);

See the app.setAsDefaultProtocolClient API for more details.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

A remote code execution vulnerability has been discovered in Google Chromium that affects all recent versions of Electron. Any Electron app that accesses remote content is vulnerable to this exploit, regardless of whether the sandbox option is enabled.

We've published two new versions of electron 1.7.8 and 1.6.14, both of which include a fix for this vulnerability. We urge all Electron developers to update their apps to the latest stable version immediately:

npm i electron@latest --save-dev

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

Please contact security@electronjs.org if you wish to report a vulnerability in Electron.