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.

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.