Theo De Raadt planea reforzar o mecanismo de protección da memoria W^X (Write XOR Execute). A esencia do mecanismo é que non se pode acceder simultáneamente ás páxinas da memoria do proceso para a súa escritura e execución. Así, o código pódese executar só despois de que a escritura estea desactivada, e a escritura nunha páxina de memoria só é posible despois de que a execución estea desactivada. O mecanismo W^X axuda a protexer as aplicacións do espazo do usuario de ataques de desbordamento de búfer comúns, incluíndo desbordamentos de pila, e está activo en OpenBSD .
Desde o inicio do traballo en W^X, estaba claro que era un longo camiño, xa que había un número importante de aplicacións que usaban JIT. As implementacións JIT pódense dividir en tres categorías:
- Cambiando a memoria entre os estados W e X, aceptando o "custo" da chamada do sistema .
- Creación de alias entre un par de asignacións W e X da mesma memoria.
- A opción máis "sucia" require un modelo de memoria W|X que permita a gravación e a execución simultáneas.
Actualmente, hai moito menos programas que usan a terceira opción e máis que utilizan a primeira e a segunda. Non obstante, dado que era necesario executar programas con W|X JIT (principalmente Chromium e Iridum), engadiuse unha opción de montaxe do sistema de ficheiros "wxallowed", que permitía empregar a memoria simultaneamente tanto para a escritura como para a execución, no caso de que o executable ELF o ficheiro está marcado co marcador "wxneeded" e as propias aplicacións foron protexidas adicionalmente mediante mecanismos и para limitar a lista de chamadas ao sistema utilizadas e partes do sistema de ficheiros dispoñibles para a aplicación, respectivamente.
Para complicar aínda máis a explotación de vulnerabilidades deste tipo de aplicacións, proponse un engadido ao mecanismo , que comproba se a chamada ao sistema se está a executar desde unha páxina de memoria escribible. Se a páxina se pode escribir, o proceso vese obrigado a finalizar. Deste xeito, un atacante non poderá explotar as chamadas do sistema e verase obrigado a tentar atopar os gadgets necesarios na implementación de JIT ou mesmo realizar o traballo máis difícil de detectar as chamadas do sistema directamente dentro. .
Os procesos de Chrome/Iridium xa están protexidos de forma bastante fiable mediante promesa e revelación, pero eliminar a posibilidade de usar, por exemplo, a chamada ao sistema write(2) obviamente ten algunha vantaxe, xa que crea dificultades adicionais para o atacante. Non obstante, tamén poden xurdir dificultades se a implementación JIT utiliza chamadas nativas do sistema desde a memoria W|X. Non obstante, hai motivos para esperar que non sexa así, xa que o ABI foi modificado varias veces, pero ninguén informou nunca de problemas.
Os cambios xa están dispoñibles en instantáneas habituais da rama OpenBSD-Actual, todos os interesados están invitados a probalos.
As noticias relacionadas sobre a aparición do modo en Chrome/Iridium merecen un comentario aparte de Theo . Desde o seu punto de vista, isto é aceptable para algúns modelos de uso, pero probablemente non para todos, xa que este modo obviamente aumentará a carga do procesador. Actualmente, Chrome funcionará principalmente se desactivas "wxallowed" para /usr/local, aínda que pode haber problemas con algunhas extensións (ghostery é un exemplo). Dun xeito ou doutro, Theo espera que o traballo completo no modo JITless se poña a un estado totalmente operativo nun futuro próximo.
Fonte: opennet.ru