La zona de pruebas de Google Chrome V8 ya no es experimental

La implementación de la zona de pruebas en el motor JavaScript V8 de Google está lo suficientemente madura como para que ya no se considere una característica experimental. Los desarrolladores de V8 escriben sobre esto en su blog y señalan que el sandboxing ahora también forma parte del “Programa de recompensas de vulnerabilidad” de Chrome. Los investigadores de seguridad que descubran vulnerabilidades en el sandbox ahora pueden recibir una recompensa financiera de Google.

anuncio

El sandbox V8 ha estado activo en las versiones de 64 bits de Chrome para sistemas operativos normales desde la versión 103 del navegador, es decir, durante unos dos años. Pero hasta ahora se ha considerado como un mecanismo de protección experimental en el que aún se esperan lagunas. Al incluirlo en el Programa de recompensas de vulnerabilidad, la funcionalidad se habilita y la versión 123 actual de Chrome se convierte en una versión beta del sandbox V8, explican los desarrolladores.

Sin indicadores por favor

La zona de pruebas incluye un área de memoria del motor V8 llamada “montón” y generalmente funciona al no permitir punteros regulares: los objetos en la zona de pruebas no pueden hacer referencia directa a otros objetos. Debe utilizar un “puntero comprimido”, que es solo un desplazamiento y no puede apuntar a la memoria fuera del entorno limitado, o utilizar una referencia indirecta a través de la tabla de punteros. La tabla también contiene información de tipo y se puede utilizar para comprobar si una referencia es legítima o no.

Los cálculos de desplazamiento, especialmente las direcciones indirectas, afectan el rendimiento, pero sólo ligeramente. Los desarrolladores señalan una pérdida de rendimiento típica de alrededor del uno por ciento, lo que bien vale los beneficios de seguridad esperados del sandbox, especialmente porque es difícil de lograr usando otras medidas. Los fallos conocidos en V8 a menudo no dependen directamente de errores clásicos de acceso a la memoria sino, por ejemplo, de errores lógicos en el compilador justo a tiempo. Sólo entonces se producen errores de acceso, normalmente en el montón.

El sandbox también puede detectar errores de acceso que se producen de forma indirecta, mientras que otras medidas habituales no funcionan en estos casos. Por ejemplo, de nada sirven las garantías de un lenguaje “seguro para la memoria” como Rust cuando hay errores lógicos en el compilador. en comparte su blog Los desarrolladores explican en detalle cómo funciona el sandbox V8 y por qué otras contramedidas como el “etiquetado de memoria” no funcionan bien en el caso específico del motor JavaScript.

Sin embargo, todavía existen algunos problemas en el sandbox actual y hay recompensas disponibles para las vulnerabilidades. Condiciones especiales enlace. Sin embargo, las vulnerabilidades de Sandbox descubiertas hasta ahora son errores de acceso tradicionales que también pueden exponer otras medidas preventivas. En última instancia, impedir el escape del arenero debería ser más fácil que impedir el escape del propio V8. Al menos esa es la esperanza de los desarrolladores.

(colocar)