10 articles tagués avec "Sécurité"

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.

Comment cela pourrait-il avoir un impact pour moi?​

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.

Suis-je impacté?​

Par défaut, toutes les versions publiées d'Electron ont les fonctionnalités runAsNode et enableNodeCliInspectArguments activées. 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.

Atténuation​

La façon la plus simple d'atténuer ce problème est de désactiver le fusible runAsNode dans votre application Electron. Le fuse runAsNode acitve ou désactive le respect de la variable d'environnement ELECTRON_RUN_AS_NODE. 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).

Vous pouvez trouver plus d'informations sur les meilleures pratiques de sécurité que nous recommandons pour les applications Electron dans notre Liste de contrôle de sécurité.

Plus d’une semaine s’est écoulée depuis que CVE-2023-4863 : Heap buffer overflow in WebP a été rendu public, entraînant une vague de nouvelles versions des webp de rendu logiciel : macOS, iOS, Chrome, Firefox et diverses distributions Linux ont tous reçu des mises à jour. Cela fait suite aux enquêtes menées par Citizen Lab, qui a découvert qu’un iPhone utilisé par une « organisation de la société civile basée à Washington DC » était attaqué à l’aide d’un exploit sans clic dans iMessage.

Pour Electron, nous sommes également passé à l’action et a publié de nouvelles versions le jour même : Si votre application affiche du contenu fourni par l’utilisateur, vous devez mettre à jour votre version d’Electron - v27.0.0-beta.2, v26.2.1, v25.8.1, v24.8.3 et v22.3.24 contiennent toutes une version corrigée de libwebp, la bibliothèque responsable du rendu des images webp.

Maintenant que nous sommes tous nouvellement conscients qu’une interaction aussi innocente que « le rendu d'une image » soit une activité potentiellement dangereuse, nous voulons profiter de cette occasion pour rappeler à tous que Electron est livré avec un bac à sable des processus qui limitera le rayon d’action d'une éventuelle grosse attaque - quelle qu’elle soit.

Le bac à sable était disponible depuis Electron v1 et activé par défaut dans v20, mais nous savons que de nombreuses applications (en particulier celles qui existent depuis un certain temps) peuvent avoir un sandbox: false quelque part dans leur code – ou un nodeIntegration: true, qui désactive également la sandbox lorsqu’il n’y a pas de paramètre sandbox explicite. C’est compréhensible : Si vous êtes avec nous depuis longtemps, vous avez probablement apprécié le pouvoir de lancer un require("child_process") ou un require("fs") dans le même code qui exécute votre HTML/CSS.

Avant de parler de comment migrer vers le bac à sable, voyons d’abord pourquoi vous le souhaitez.

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. Vous pouvez en lire d'avantage à ce sujet dans ce billet du Chrome Blog .

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.

Portée​

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

Atténuation​

Affected apps should upgrade to a patched version of Electron.

Nous avons publié de nouvelles versions d'Electron qui incluent des corrections pour cette vulnérabilité :

• 6.1.4

Electron 7.0.1 automatically included the fix from upstream, before the announcement was made. Electron 8 n'est pas non plus affecté. La vulnérabilité n'existait pas dans Electron 5, cette version n'est donc pas affectée.

Informations complémentaires ​

This vulnerability was discovered by Anton Ivanov and Alexey Kulaev at Kaspersky Labs and reported to the Chrome team. Le billet du blog Chrome peut être trouvé ici.

Pour en savoir plus sur les meilleures pratiques pour sécuriser vos applications Electron, consultez notre tutoriel de sécurité.

Si vous souhaitez signaler une vulnérabilité dans Electron, envoyez un e-mail à 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.

Portée​

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

Atténuation​

Affected apps should upgrade to a patched version of Electron.

Nous avons publié de nouvelles versions d'Electron qui incluent des corrections pour cette vulnérabilité :

• 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-bêta.5

Informations complémentaires ​

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.

Pour en savoir plus sur les meilleures pratiques pour sécuriser vos applications Electron, consultez notre tutoriel de sécurité.

Si vous souhaitez signaler une vulnérabilité dans Electron, envoyez un e-mail à security@electronjs.org.

Une vulnérabilité de code a été découverte qui permettait à Node d'être réactivé dans les fenêtres enfants.

L'ouverture d'un BrowserView avec sandbox: true ou nativeWindowOpen: true et nodeIntegration: false donne un contenu Web où window.open peut être appelé et la fenêtre enfant nouvellement ouverte aura nodeIntegration activé. Cette vulnérabilité affecte toutes les versions prises en charge d'Electron.

Atténuation​

Nous avons publié de nouvelles versions d'Electron qui incluent des corrections pour cette vulnérabilité : 2.0.17, 3.0.15, 3.1.3, 4.0.4, et 5.0.0-beta.2. Nous encourageons tous les développeurs d'Electron à mettre à jour leurs applications vers la dernière version stable immédiatement.

Si pour une raison quelconque, vous ne pouvez pas mettre à jour votre version d'Electron, vous pouvez atténuer ce problème en désactivant tous les contenus web enfants :

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

Informations complémentaires ​

Cette vulnérabilité a été trouvée et signalée de manière responsable au projet Electron par PalmerAL.

Pour en savoir plus sur les meilleures pratiques pour sécuriser vos applications Electron, consultez notre tutoriel de sécurité.

Si vous souhaitez signaler une vulnérabilité dans Electron, envoyez un e-mail à security@electronjs.org.

Une vulnérabilité d'exécution de code à distance, "Magellan," a été découverte et affecte les logiciels basés sur SQLite ou Chromium, y compris toutes les versions d'Electron.

Portée​

Les applications Electron utilisant Web SQL sont touchées.

Atténuation​

Les applications concernées doivent cesser d'utiliser Web SQL ou passer à une version corrigée d'Electron.

Nous avons publié de nouvelles versions d'Electron qui incluent des corrections pour cette vulnérabilité :

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

Aucun cas n'a été signalé dans la nature; mais les applications concernées sont priées de prendre des mesures d'atténuation.

Informations complémentaires ​

Cette vulnérabilité a été découverte par l'équipe de Tencent Blade, qui a publié un billet de blog qui traite de la vulnérabilité.

Pour en savoir plus sur les meilleures pratiques pour sécuriser vos applications Electron, consultez notre tutoriel de sécurité.

Si vous souhaitez signaler une vulnérabilité dans Electron, envoyez un e-mail à security@electronjs.org.

Une vulnérabilité d'exécution de code à distance a été découverte dans les applications ayant la capacité d'ouvrir des fenêtres enfants imbriquées sur les versions d'Electron (3.0.0-beta.6, 2.0.7, 1.8.7 et 1.7.15). Cette vulnérabilité a été assignée à l'identifiant CVE CVE-2018-15685.

Plateformes affectées​

Vous êtes impacté si :

1. Vous intégrez n'importe quel contenu d'utilisateur distant, même dans une sandbox
2. Vous acceptez des entrées utilisateur présentant des vulnérabilités XSS

Détails

Vous êtes impacté si un code utilisateur s'exécute à l'intérieur d'une iframe / peut créer une iframe. Étant donné la possibilité d'une vulnérabilité XSS, on peut supposer que la plupart des applications sont vulnérables à ce cas.

Vous êtes également impacté si vous ouvrez l'une de vos fenêtres avec l'option nativeWindowOpen: true ou sandbox: true. Bien que cette vulnérabilité nécessite également une vulnérabilité XSS pour exister dans votre application, vous devriez quand même appliquer l'une des mesures ci-dessous si vous utilisez l'une de ces options.

Atténuation​

Nous avons publié de nouvelles versions d'Electron qui incluent des corrections pour cette vulnérabilité : 3.0.0-beta.7, 2.0.8, 1.8.8, et 1.7.16. Nous demandons instamment à tous les développeurs Electron de mettre à jour leurs applications vers la dernière version stable immédiatement.

Si, pour une raison quelconque, vous n'êtes pas en mesure de mettre à jour votre version d'Electron, vous pouvez protéger votre application en appelant de manière générale event.preventDefault() sur l'événement new-window pour tous les webContents. Si vous n'utilisez pas du tout window.open ou aucune fenêtre enfant, c'est aussi une atténuation valide pour votre application.

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

Si vous comptez sur la capacité de vos fenêtres enfant à créer des fenêtres petit-enfant, une troisième stratégie d'atténuation consiste à utiliser le code suivant sur votre fenêtre de niveau supérieur :

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

Ce code fera en sorte que la webPreferences de la fenêtre de niveau supérieur soit appliquée manuellement à toutes les fenêtres enfants à l'infini.

Informations complémentaires ​

Cette vulnérabilité a été découverte et signalée de manière responsable au projet Electron par Matt Austin de Contrast Security.

Pour en savoir plus sur les meilleures pratiques pour sécuriser vos applications Electron, consultez notre tutoriel de sécurité.

Si vous souhaitez signaler une vulnérabilité dans Electron, envoyez un e-mail à security@electronjs.org.

Une vulnérabilité a été découverte qui permettait de réactiver l'intégration de Node.js dans certaines applications Electron qui la désactivent. L’identificateur CVE CVE a été attribué à cette vulnérabilitéCVE-2018-1000136.

Applications concernées​

Une application est affectée si toutes les conditions suivantes sont remplies :

1. Fonctionne sur Electron 1.7, 1.8 ou une version bêta 2.0.0
2. Permet l’exécution de code distant arbitraire
3. Désactive l'intégration de Node.js
4. Ne déclare pas explicitement webviewTag: false dans ses webPreferences
5. N’active pas l’option nativeWindowOption
6. N'intercepte pas les événements new-window et surcharge manuellement event.newGuest sans utiliser le tag d'options fournie

Bien que cela ne semble concerner qu'une minorité d'applications Electron, nous vous encourageons à ce que toutes les applications soient mises à jour par précaution.

Atténuation​

Cette vulnérabilité est corrigée dans les versions d'aujourd'hui de 1.7.13, 1.8.4et 2.0.0-beta.5.

Les développeurs ne pouvant pas mettre à niveau la version Electron de leur application peuvent atténuer la vulnérabilité avec le code suivant :

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

// et *SI* vous n'utilisez aucune WebViews,
// vous pourriez aussi vouloir
app.on('web-contents-created', (event, win) => {
  win.on('will-attach-webview', (event, webPreferences, params) => {
    event.preventDefault();
  });
});

Informations complémentaires ​

Cette vulnérabilité a été trouvée et signalée de manière responsable au projet Electron par Trustwave SpiderLabs.

Pour en savoir plus à propos des meilleures pratiques pour sécuriser vos applications Electron, consultez notre tutoriel de sécurité.

Si vous souhaitez signaler une vulnérabilité dans Electron, envoyez un e-mail à security@electronjs.org.

Veuillez vous inscrire à notre liste de diffusion recevoir des mises à jour sur les versions et les mises à jour de sécurité.

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.

Plateformes affectées​

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.

Atténuation​

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 pour une raison quelconque, vous ne pouvez pas mettre à jour votre version d'Electron, vous pouvez ajouter -- comme dernier argument en appelant l'application . etAsDefaultProtocolClient, qui empêche Chromium d'analyser d'autres 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',
  '--',
]);

Voir l'API app.setAsDefaultProtocolClient pour plus de détails.

Voir l'API app.setAsDefaultProtocolClient pour plus de détails.

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. Toute application Electron qui accède au contenu à distance est vulnérable à cet exploit, que l'option sandbox soit activée.

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

Pour en savoir plus sur les bonnes pratiques pour sécuriser les applications Electron, consultez notre tutoriel de sécurité .

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