Saltar al contenido principal

Incluir a la barrera: Fortalecer las aplicaciones con SandBox

· 5 lectura mínima

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.

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.

Don’t be scared by the number of line changes, most of it is in <code>package-lock.json</code>

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.