A finales de la semana pasada, nuestra distro Slackware Linux anunció una actualización para seguir la programada y esperada versión de Firefox 100, que salió a principios de mes.
La nueva versión es 100.0.1, y funciona correctamente.
Pero cuando hicimos clic en “What’s new” dos días después, para ver qué había de nuevo, seguía diciendo [2022-05-15T19:00Z] que “volviéramos a comprobarlo más tarde”:
Del mismo modo, la comprobación de las actualizaciones a través del cuadro de diálogo “Acerca de” en una versión de Firefox que habíamos instalado directamente desde Firefox.com nos informó de que estábamos al día en la versión 100.0.
Visitar Firefox.com directamente tampoco ayudó, la versión 100.0 también aparecía allí como la última y mejor descarga.
Sin embargo, la 100.0.1 está disponible oficialmente en el servidor de archivos FTP de Mozilla (aunque ya no se puede acceder a ella a través de FTP, por supuesto).
Según Ghacks.com, el cambio más significativo en 100.0.1 es que la versión puntual “mejora el sandbox de seguridad de Firefox en dispositivos Windows”.
Un vistazo al registro de cambios de Mozilla y a un reciente artículo del blog Mozilla Hacks sugiere que Ghacks.com ha identificado, efectivamente, el gran problema de esta versión liberada-pero-aún-no-lanzada.
El artículo del blog, titulado Improved Process Isolation in Firefox 100, en realidad se publicó el día antes de que la versión 100.0.1 se subiera al servidor FTP, como si los cambios ya se hubieran realizado en la versión 100.0.
Sin embargo, por lo que podemos decir, este código de seguridad no fue finalmente habilitado (o al menos no fue completamente habilitado) en la versión 100.0, porque los registros de cambios de Mozilla incluyen una corrección para el error 1767999, fechado poco después de que saliera la versión 100.0, titulado Re-enable Win32k Lockdown by Default.
(Más adelante explicaremos cómo este código del sandbox de seguridad llegó a llamarse Win32k Lockdown).
¿Qué hay de nuevo en el sandbox?
El informe sobre la mejora del aislamiento de procesos describe una larga serie de cambios en Firefox que tienen como objetivo aprovechar una configuración de seguridad de Windows conocida desde hace tiempo como PROCESS_MITIGATION_SYSTEM_CALL_DISABLE_POLICY.
No se trata de una nueva característica de seguridad (llegó en Windows 8), pero no es una mitigación que se pueda aplicar fácilmente a productos visuales, interactivos y de representación gráfica como los navegadores.
Simplificando mucho, el ajuste SYSTEM_CALL_DISABLE permite que un proceso renuncie al derecho de hacer ciertas llamadas al sistema peligrosas, especialmente aquellas funciones de la API de Windows que se implementan directamente en el núcleo por razones de rendimiento.
Firefox ya se divide a sí mismo en muchos procesos separados, de modo que si el navegador se vuelve loco en una pestaña, el código comprometido no tiene inmediatamente acceso al mismo espacio de memoria que todas las demás pestañas.
Los primeros navegadores solían funcionar como un único proceso monolítico que se encargaba de establecer conexiones de red, gestionar las descargas, renderizar el contenido suministrado de forma remota, ejecutar código JavaScript no fiable y mostrar tantas ventanas o pestañas como tuvieras abiertas.
En general, esto aumentaba el rendimiento, porque mover los datos dentro de un gran proceso es mucho más fácil y rápido (aunque más propenso a errores) que transmitirlos entre procesos separados.
Pero significaba que el código de explotación activado en una pestaña del navegador podía llevar directamente a los atacantes a husmear en las contraseñas, cookies y otros contenidos confidenciales de cualquier otra pestaña o ventana del navegador abierta en ese momento.
Divide y vencerás
Dividir el navegador en múltiples procesos cooperativos pero separados significa que cada uno tiene su propia área de memoria que los otros no pueden ver.
Los procesos separados también permiten que diferentes partes del navegador se ejecuten con diferentes derechos de acceso, de acuerdo con el principio de mínimo privilegio (nunca te des más poder del que realmente necesitas, aunque sólo sea para protegerte de ti mismo).
Se podría pensar, por lo tanto, que implementar SYSTEM_CALL_DISABLE sería un cambio obvio y fácil de hacer en los procesos de renderización de contenido web de un navegador, dado que su trabajo es decodificar, manejar, procesar y mostrar contenido basado en datos no fiables recibidos desde el exterior.
Esos datos no fiables pueden incluir imágenes deliberadamente trucadas, archivos de fuentes astutamente elaborados, código JavaScript malévolo y de mal comportamiento y mucho más, por lo que impedir voluntariamente que esos procesos realicen llamadas a funciones de riesgo en el núcleo de Windows parece un ajuste de seguridad imprescindible.
Después de todo, un error o un fallo en el núcleo es mucho más peligroso que un fallo en la zona de usuario, dado que es el propio núcleo el que se supone que controla el mal comportamiento del código de la zona de usuario.
Si buscas una metáfora dramática, puedes pensar en un exploit en la parte de usuario como una manipulación de un testigo en un juicio, pero puedes pensar en un exploit en la parte del kernel como si se tratara de eludir a los testigos y subvertir al juez y al jurado.
Desafortunadamente, como los programadores de Mozilla han tenido mucho tiempo para reflexionar, las funciones de la API de Windows que Microsoft decidió cambiar de tierra de usuario a tierra del núcleo eran las funciones que más afectaban al rendimiento en tiempo real y, por tanto, las más obvias para los usuarios (y las que más se quejaban de ellas), como la escritura en la pantalla, la visualización de gráficos e incluso, como descubrió Mozilla, la decisión de dónde añadir saltos de línea en el texto formateado en idiomas con complejas reglas de formato de texto.
En otras palabras, cualquier proceso de renderizado del navegador que quiera tener la seguridad añadida de SYSTEM_CALL_DISABLE necesita ser capaz de llamar a otro proceso de propósito especial al que se le permita llamar a funciones de la API del nivel del núcleo de Windows de una manera bien controlada.
Si los procesos de ayuda que actúan como “aislantes” entre los procesos de renderizado y el kernel omiten cualquier función en la que el navegador confíe en última instancia (incluso si sólo se necesitan ocasionalmente, como esas reglas de salto de línea de mayúsculas y minúsculas), entonces algunos sitios web simplemente dejarán de funcionar, o funcionarán incorrectamente.
¿Por qué ahora?
Mozilla se refiere a su uso de la opción SYSTEM_CALL_DISABLE como Win32k Lockdown, por el nombre del controlador de Windows (win32k.sys) que implementa las diversas llamadas a la API de Windows aceleradas por el núcleo.
Dado que el código ha tardado mucho tiempo en ser creado, y aparentemente casi-pero-no está listo para ser activado por defecto en Firefox 100 ¿por qué apresurarse a activarlo en una actualización de la versión 100.0.1 en lugar de esperar a una futura versión programada?
Una razón se insinúa en el resumen de la última Reunión de Canales de Mozilla, que dice: “Recordatorio: pwn2own es la próxima semana (miércoles-viernes) y esperamos enviar chemspills [la curiosa metáfora de Mozilla para las actualizaciones rápidas de seguridad] en respuesta… Sabremos el calendario exacto más cerca del comienzo del evento”.
Pwn2Own, por supuesto, es un famoso concurso de hacking con grandes cantidades de dinero en el que se atacan deliberadamente productos como navegadores, aplicaciones de teleconferencia y software de automoción (donde se ofrecen los mayores premios individuales de este año, que alcanzan los 500.000 dólares).
Los concursantes disponen de un espacio de 30 minutos en un ordenador recién instalado con las últimas actualizaciones del sistema operativo y de las aplicaciones para demostrar un exploit que funcione en directo ante el jurado.
Se sortea el orden en el que compiten los participantes, y el primero en “hackear” un producto gana el premio.
Esto significa, por supuesto, que sólo se divulga el primer exploit que funciona correctamente.
Los demás competidores no se llevan el dinero, pero sí pueden mantener en secreto sus ataques, por lo que nadie sabe si han encontrado un tipo de exploit diferente, o si habría funcionado si hubieran sacado un puesto anterior.
¿La urgencia de sacar la versión 100.0.1 se debe a la proximidad de la Pwn2Own, con la esperanza de que al menos algunos de los ataques que los competidores puedan traer sean frustrados por la nueva protección Win32k Lockdown?
¿Qué hacer?
No necesitas hacer nada, aunque nos solidarizamos si te confundiste al ver los informes de que Firefox 100.0.1 estaba oficialmente disponible, sólo para encontrar que no aparecerá como una actualización oficial hasta el lunes 2022-05-16 como muy pronto.
Si quieres actualizarte antes que la mayoría, puedes descargar la 100.0.1 desde el servidor FTP de Mozilla y desplegarla tú mismo, en lugar de esperar a que el mecanismo de actualización interno de Firefox decida que es el momento.
