10 publicaciones etiquetados con "Seguridad"

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.

Mitigación​

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.

Ha pasado más de una semana desde CVE-2023-4863: Se ha hecho público el desbordamiento del búfer Heap en WebP, lo que ha causado una avalancha de nuevos lanzamientos en programas para el renderizado de imágenes webp: macOS, iOS, Chrome, Firefox y varias distribuciones Linux han recibido actualizaciones. Tras las investigaciones realizadas por Citizen Lab, se ha descubierto que un iPhone utilizado por una "organización de la sociedad civil unicada en Washington DC" estuvo bajo ataque por medio de una vulnerabilidad de cero-clicks en iMessage.

Electron, también, entró en acción y publicó nuevas versiones el mismo día: Si tu aplicación renderiza cualquier contenido proporcionado por el usuario, debes actualizar tu versión de Electron - v27.0.0-beta.2, v26.2.1, v25.8.1, v24.8.3 y v22.3.23, todas contienen una versión corregida de libwebp, la librería responsable de renderizar imágenes webp.

Ahora que estamos enterados de que una interacción tan inocente como "renderizar una imagen" es una actividad potencialmente peligrosa, aprovechamos esta oportunidad para recordar a todos que Electron incluye un sandbox de procesos que limita el radio de explosión del siguiente gran ataque — sin importar lo que sea.

El sandbox ha estado disponible desde Electron v1 y está activado por defecto en v20, pero sabemos que varias aplicaciones (especialmente aquellas que están disponibles desde hace tiempo) podrían tener un sandbox: false en cualquier parte del código – o un nodeIntegration: true que, igualmente, desactiva el sandbox cuando no hay un ajuste de sandbox explícito. Eso es comprensible: si has estado con nosotros durante un largo tiempo, probablemente has disfrutado el poder de lanzar un require("child_process") o require("fs") en el mismo código que ejecuta tu HTML/CSS.

Antes de hablar sobre cómo migrar al sandbox, primero discutamos por qué lo quieres.

El sandbox pone una jaula dura alrededor de todos los procesos de renderizado, garantizando que sin importar lo que suceda dentro, el código es ejecutado en un entorno restringido. Como concepto, es mucho más viejo que Chromium y es proporcionado como una característica en todos los sistemas operativos. El sandbox de Electron y Chromium es construido en base a estas características del sistema. Incluso si nunca has mostrado contenido generado por el usuario, deberías considerar la posibilidad de que tu renderizado puede verse comprometido: Escenarios tan complejos como los ataques a la cadena de suministros y tan sencillos como pequeños errores, pueden causar que tu renderizado realice acciones que no planeabas.

El entorno de pruebas hace que ese escenario sea mucho menos aterrador: un proceso dentro consigue usar libremente ciclos de CPU y memoria — eso es todo. Los procesos no pueden escribir en el disco o mostrar sus propias ventanas. En el caso de nuestro libwep error, el sandbox se asegura de que un atacante no pueda instalar o ejecutar malware. De hecho, en el caso del ataque Pegasus original contra el iPhone, de los empleados. el ataque se dirigió específicamente a un proceso de imagen que no es de arena para obtener acceso al teléfono, rompiendo primero los límites del iMessage normalmente encendido. Cuando un CVE como el de este ejemplo es anunciado, todavía tienes que actualizar tus aplicaciones Electron a una versión segura, pero mientras tanto, la cantidad de daño que un atacante puede causar es muy limitada.

Migrar una aplicación de vainilla Electron de sandbox: false a sandbox: true es una empresa. Lo sé, porque a pesar de haber escrito personalmente el primer borrador de las Directrices de Seguridad Electron, No he conseguido migrar una de mis propias aplicaciones para usarla. Esto ha cambiado este fin de semana y les recomiendo que lo cambien también.

Hay dos cosas que tienes que tomar en cuenta:

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.

Esta vulnerabilidad ha sido asignada CVE-2019-13720. Puedes leer más al respecto en la Chrome Blog Post.

Tenga en cuenta que Chrome tiene informes de que esta vulnerabilidad se está utilizando, por lo que se recomienda encarecidamente que actualice Electron lo antes posible.

Ámbito​

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

Mitigación​

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 incluye automáticamente la corrección desde el principio, antes de que se hiciera el anuncio. El electrón 8 tampoco se ve afectado. La vulnerabilidad no existía en Electron 5, por lo que esa versión tampoco se ve afectada.

Más información​

Esta vulnerabilidad la descubrió Anton Ivanov y Alexey Kulaev en los Laboratorios Kaspersky e informó al equipo de Chrome. La entrada del blog de Chrome se puede encontrar aquí.

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

Si quieres reportar una vulnerabilidad de Electron, envía un correo electrónico a 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.

Ámbito​

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

Mitigación​

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

Más información​

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.

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

Si quieres reportar una vulnerabilidad de Electron, envía un correo electrónico a 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.

Mitigación​

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());

Más información​

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

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

Si quieres reportar una vulnerabilidad de Electron, envía un correo electrónico a security@electronjs.org.

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

Ámbito​

Electron applications using Web SQL are impacted.

Mitigación​

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.

Más información​

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

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

Si quieres reportar una vulnerabilidad de Electron, envía un correo electrónico a security@electronjs.org.

Se ha descubierto una vulnerabilidad de ejecución de un código remoto la cual afecta aplicaciones con la capacidad de abrir ventanas anidadas hijas en versiones de Electron (3.0.0-beta.6, 2.0.7, 1.8.7, and 1.7.15). La vulnerabilidad ha sido asignada al identificador CVE CVE-2018-15685.

Plataformas afectadas​

Esto te afecta si:

1. Has incrustado cualquier contenido de usuario remoto, incluso en una sandbox
2. Aceptas inputs de usuario con cualquier vulnerabilidad XSS

Detalles

Esto te afecta si cualquier código de usuario se ejecuta dentro de iframe / si puede crear un iframe. Dada la posibilidad de una vulnerabilidad XSS, se puede asumir que la mayoría de aplicaciones son vulnerables a este caso.

Esto te afecta si abres cualquiera de tus ventanas con las opciones nativeWindowOpen: true o sandbox: true. A pesar de que esta vulnerabilidad también requiere que exista una vulnerabilidad XSS en tu aplicación, deberías aplicar una de las mitigaciones de abajo si utilizas alguna de estas opciones.

Mitigación​

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. Le pedimos a todos los desarrolladores de Electron a que actualicen sus aplicaciones a la más reciente versión estable ahora mismo.

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'. Si no utilizas window.open o ninguna ventana hija en absoluto, entonces esta también es una mitigación válida para tu aplicación.

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

Si dependes de la capacidad de tus ventanas hijas para crear ventanas de nietos, entonces una tercera estrategia de mitigación requiere utilizar el siguiente código en tu ventana de nivel superior:

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);

Este código forzará manualmente las ventanas de nivel superior (webPreferences) sean aplicadas a todas las ventanas hijas de manera infinitamente profunda.

Más información​

Esta vulnerabilidad fue encontrada y reportada responsablemente al proyecto Electron por Matt Austin de Contrast Security.

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

Si quieres reportar una vulnerabilidad de Electron, envía un correo electrónico a security@electronjs.org.

A vulnerability has been discovered which allows Node.js integration to be re-enabled in some Electron applications that disable it. La vulnerabilidad ha sido asignada al identificador CVE 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.

Mitigación​

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();
  });
});

Más información​

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

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

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.

Plataformas afectadas​

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.

Mitigación​

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.

Si por alguna razón no puede actualizar su versión de Electron puedes añadir -- como último argumento al llamar a aplicación. etAsDefaultProtocolClient, que evita que Chromium analice más opciones. The double dash -- signifies the end of command options, after which only positional parameters are accepted.

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

Vea la app.setAsDefaultProtocolent API para más detalles.

Para obtener más información sobre las mejores prácticas para mantener sus aplicaciones Electron seguras, vea nuestro tutorial de seguridad.

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

Se ha descubierto una vulnerabilidad de ejecución de código remoto en Google Chromium que afecta a todas las versiones recientes de Electron. Cualquier aplicación Electron que acceda a contenido remoto es vulnerable a este exploit, independientemente de si la opción sandbox está activada.

Hemos publicado dos nuevas versiones de electrón 1.7.8 y 1.6.14, las cuales incluyen una corrección para esta vulnerabilidad. Le pedimos a todos los desarrolladores de Electron a que actualicen sus aplicaciones a la versión más reciente estable ahora mismo:

npm i electron@latest --save-dev

Para obtener más información sobre las mejores prácticas para mantener sus aplicaciones Electron seguras, vea nuestro tutorial de seguridad.

Póngase en contacto con security@electronjs.org si desea reportar una vulnerabilidad en Electron.