Theo De Raadt planea fortalecer el mecanismo de protección de memoria W^X (Write XOR Execute). La esencia del mecanismo es que no se puede acceder simultáneamente a las páginas de la memoria del proceso para escribir y ejecutar. Por lo tanto, el código se puede ejecutar sólo después de deshabilitar la escritura, y escribir en una página de memoria sólo es posible después de deshabilitar la ejecución. El mecanismo W^X ayuda a proteger las aplicaciones del espacio de usuario de ataques comunes de desbordamiento del búfer, incluidos los desbordamientos de pila, y está activo en OpenBSD. .
Desde el inicio del trabajo en W^X, quedó claro que se trataba de un camino largo, ya que había un número importante de aplicaciones que utilizaban JIT. Las implementaciones JIT se pueden dividir en tres categorías:
- Cambiar la memoria entre los estados W y X, aceptando el “costo” de la llamada al sistema .
- Crear alias entre un par de asignaciones W y X de la misma memoria.
- La opción más “sucia” requiere un modelo de memoria W|X que permita grabación y ejecución simultánea.
Actualmente, hay muchos menos programas que utilizan la tercera opción y más que utilizan la primera y la segunda. Sin embargo, como era necesario ejecutar programas con W|X JIT (principalmente Chromium e Iridum), se agregó una opción de montaje del sistema de archivos "wxallowed", que permitía usar la memoria simultáneamente tanto para escritura como para ejecución, en caso de que el ejecutable ELF El archivo está marcado con el marcador "wxneeded" y las aplicaciones mismas fueron protegidas adicionalmente mediante mecanismos. и para limitar la lista de llamadas al sistema utilizadas y partes del sistema de archivos disponibles para la aplicación, respectivamente.
Para complicar aún más la explotación de vulnerabilidades en dichas aplicaciones, se propone una adición al mecanismo. , que comprueba si la llamada al sistema se está ejecutando desde una página de memoria grabable. Si se puede escribir en la página, el proceso se ve obligado a finalizar. De esta manera, un atacante no podrá explotar las llamadas al sistema y se verá obligado a intentar encontrar los dispositivos necesarios en la implementación JIT o incluso a realizar el trabajo más difícil de detectar códigos auxiliares de llamadas al sistema directamente dentro. .
Los procesos de Chrome/Iridium ya están protegidos de manera bastante confiable mediante promesa y revelación, pero eliminar la capacidad de usar, por ejemplo, la llamada al sistema write(2) obviamente tiene alguna ventaja, ya que crea dificultades adicionales para el atacante. Sin embargo, también pueden surgir dificultades si la implementación JIT utiliza llamadas nativas al sistema desde la memoria W|X. Sin embargo, hay motivos para esperar que este no sea el caso, ya que el ABI se ha modificado varias veces, pero nadie ha informado nunca de problemas.
Los cambios ya están disponibles en las instantáneas regulares de la rama OpenBSD-Current, todos los interesados están invitados a probarlos.
Las noticias relacionadas sobre la aparición del modo en Chrome/Iridium merecen un comentario aparte por parte de Theo. . Desde su punto de vista, esto es aceptable para algunos modelos de uso, pero probablemente no para todos, ya que este modo obviamente aumentará la carga en el procesador. Actualmente, Chrome funcionará principalmente si desactivas "wxallowed" para /usr/local, aunque puede haber problemas con algunas extensiones (ghostery es un ejemplo). De una forma u otra, Theo espera que el trabajo completo en modo JITless llegue a un estado completamente operativo en un futuro próximo.
Fuente: opennet.ru