Brèche dans la barrière : Comment Renforcer les applications avec le bac à sable

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.

Le bac à sable isole strictement tous les processus de rendu et garantit que, quoi qu’il arrive à l’intérieur, le code s’exécute dans un environnement limité. En tant que concept, c’est bien plus ancien que Chromium, et c’est une fonctionnalité proposée par tous les principaux systèmes d’exploitation. Le bac à sable d’Electron et de Chromium s’appuie sur ces fonctionnalités système. Même si vous n’affichez jamais de contenu généré par les utilisateurs, vous devez envisager la possibilité que votre moteur de rendu soit compromis : des scénarios aussi sophistiqués que des attaques sur la chaîne d’approvisionnement, ou aussi simples que de petits bugs, peuvent amener votre moteur de rendu à faire des choses que vous n’aviez pas vraiment prévues.

Le bac à sable rend ce scénario beaucoup moins inquiétant : un processus à l’intérieur peut utiliser librement le processeur et la mémoire — et c’est tout. Les processus ne peuvent pas écrire sur le disque ni créer leurs propres fenêtres. Dans le cas de notre bug libwep, le bac à sable garantit qu’un attaquant ne peut ni installer ni exécuter de malware. En fait, dans le cas de l’attaque Pegasus initial sur l’iPhone d’un employé, l’attaque ciblait spécifiquement un processus d’image non isolé pour accéder au téléphone, en sortant d’abord des limites de l’iMessage, normalement sandboxée. Quand un CVE comme celui de cet exemple est annoncé, vous devez toujours mettre à jour vos applications Electron vers une version sécurisée — mais entre-temps, la quantité de dégâts qu'un attaquant peut faire est limitée de façon spectaculaire.

Migration d'une application Electron vanilla de sandbox: false vers sandbox: true est une entreprise. Je sais, parce que même si j'ai personnellement écrit la première ébauche des Directives de sécurité d'Electron, Je n'ai pas réussi à migrer une de mes applications pour l'utiliser.

Il y a deux choses que vous devez aborder:

1. Si vous utilisez le code Node.js dans les scripts preload ou WebContents, vous devez déplacer tout ce noeud. , l'interaction avec le processus principal (ou, si vous êtes fantaisie, un processus utilitaire). Compte tenu de la puissance des moteurs de rendu devenus, il y a de fortes chances que la grande majorité de votre code n'ait pas vraiment besoin de refactorisation.

   Consultez notre documentation sur Communication Inter-Processus. Dans mon cas, J'ai déplacé et encapsulé beaucoup de code dans ipcRenderer.invoke() et ipcMain.handle(), mais le processus était simple et rapide.

2. Depuis l'activation du sandbox désactive l'intégration de Node.js dans vos scripts de préchargement, vous ne pouvez plus utiliser require("../my-script"). En d'autres termes, votre script de préchargement doit être un seul fichier.

   Il existe plusieurs façons de procéder : Webpack, esbuild, parcel, et rollup feront tous l'affaire.

En fin de compte, tout le processus m'a pris environ quatre jours — et cela comprend beaucoup de gratter ma tête à la manière de disputer la puissance massive du Webpack parce que j'ai décidé d'utiliser l'occasion de refactoriser mon code de bien d'autres façons, aussi.