Teo De Raadt planes para reforzar el mecanismo de protección de memoria W^X (Write XOR Execute). La esencia del mecanismo es que las páginas de memoria del proceso no pueden estar accesibles para escritura y ejecución al mismo tiempo. Así, el código solo puede ejecutarse después de prohibir la escritura, y la escritura en la página de memoria solo es posible después de prohibir la ejecución. El mecanismo W^X ayuda a proteger las aplicaciones en el espacio de usuario contra ataques típicos, realizados a través del desbordamiento de búfer, incluidos los desbordamientos de pila y está activo en OpenBSD. .
Desde el comienzo del trabajo en W^X, estaba claro que este sería un camino largo, ya que existe una cantidad significativa de aplicaciones que utilizan JIT. Las implementaciones de JIT se pueden dividir en tres categorías:
- Cambiando la memoria entre los estados W y X, aceptando el 'costo' de la llamada al sistema. .
- Creando alias entre un par de mapeos W y X de la misma memoria.
- La opción más 'sucia' es la que requiere un modelo de memoria W|X, permitiendo la escritura y ejecución al mismo tiempo.
En la actualidad, hay significativamente menos programas que utilizan la tercera opción y más que utilizan la primera y segunda. Sin embargo, dado que era necesario ejecutar también programas con JIT W|X (principalmente, Chromium e Iridum), se agregó la opción de montar el sistema de archivos 'wxallowed', que permitía el uso de memoria tanto para escritura como para ejecución, en caso de que el archivo ELF ejecutable estuviera marcado con el indicador 'wxneeded', y las propias aplicaciones además se protegían utilizando mecanismos y para restringir la lista de llamadas al sistema utilizadas y las partes del sistema de archivos disponibles para la aplicación respectivamente.
Para complicar aún más la explotación de vulnerabilidades en tales aplicaciones, se propuso un complemento del mecanismo , que verifica si la llamada al sistema se ejecuta desde una página de memoria accesible para escritura. Si la página está disponible para escritura, el proceso se termina forzosamente. De este modo, el atacante no podrá utilizar llamadas al sistema y se verá obligado a intentar encontrar los gadgets necesarios en la implementación de JIT o incluso realizar un trabajo más arduo para detectar los parches de las llamadas al sistema directamente dentro de .
Los procesos de Chrome/Iridium están bastante protegidos mediante pledge y unveil, pero eliminar la posibilidad de usar, por ejemplo, la llamada de sistema write(2), claramente tiene ciertas ventajas, ya que crea dificultades adicionales para el atacante. Sin embargo, también pueden surgir complicaciones si la implementación de JIT utiliza llamadas de sistema nativas desde la memoria W|X. No obstante, hay razones para esperar que esto no ocurra, ya que ABI ha cambiado varias veces y nunca se han reportado problemas.
Los cambios ya están disponibles en las instantáneas regulares de la rama OpenBSD-CURRENT, todos los interesados están invitados a probar.
Theo merece un comentario aparte por las noticias relacionadas sobre la aparición en Chrome/Iridium del modo . Desde su punto de vista, esto es aceptable para algunos modelos de uso, sin embargo, probablemente no para todos, ya que en este modo la carga en el procesador aumentará evidentemente. Actualmente, Chrome funcionará principalmente si se desactiva «wxallowed» para /usr/local, aunque es probable que haya problemas con algunas extensiones (se menciona a ghostery como ejemplo). De cualquier manera, Theo espera que el funcionamiento completo en modo JITless se logre en un futuro cercano.
Fuente: opennet.ru
