Saltar al contenido principal

Declaración sobre los CVE "runAsNode"

· 4 lectura mínima

Hoy temprano, el equipo de Electron fue alertado sobre varios CVEs públicos presentados recientemente contra varias aplicaciones notables de Electron. Los CVEs están relacionados a dos fuses de Electron - runAsNode y enableNodeCliInspectArguments - y afirman incorrectamente que un atacante remoto puede ser capaz de ejecutar código arbitrario a través de estos componentes si no han sido desactivados activamente.

No creemos que estos CVE se presentaran de buena fe. En primer lugar, la afirmación es incorrecta - la configuración no habilita la ejecución remota de código. En segundo lugar, las empresas citadas en estos CVE no han sido notificadas a pesar de tener programas de recompensas por errores. Por último, si bien creemos que desactivar los componentes en cuestión mejora la seguridad de la aplicación, no creemos que los CVE se hayan calificado con la gravedad correcta. “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.


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. En su lugar, le recomendamos que use Utility Processes, el cual funciona para muchos casos de usos donde se necesita un proceso independiente de Node.js (como un proceso de un servidor Sqlite o escenarios similares).

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