Theo De Raadt planeja fortalecer o mecanismo de proteção de memória W^X (Write XOR Execute). A essência do mecanismo é que as páginas da memória do processo não podem ser acessadas simultaneamente para escrita e execução. Assim, o código só pode ser executado depois que a escrita for desabilitada, e a gravação em uma página de memória só será possível depois que a execução for desabilitada. O mecanismo W^X ajuda a proteger aplicações do espaço do usuário contra ataques comuns de buffer overflow, incluindo stack overflows, e está ativo no OpenBSD .
Desde o início dos trabalhos no W^X ficou claro que este era um longo caminho, uma vez que havia um número significativo de aplicações utilizando JIT. As implementações JIT podem ser divididas em três categorias:
- Alternando a memória entre os estados W e X, aceitando o “custo” da chamada do sistema .
- Criação de aliases entre um par de mapeamentos W e X da mesma memória.
- A opção mais “suja” requer um modelo de memória W|X que permita gravação e execução simultâneas.
Atualmente, há significativamente menos programas que utilizam a terceira opção e mais programas que utilizam a primeira e a segunda. Porém, como era necessário executar programas com W|X JIT (principalmente Chromium e Iridum), foi adicionada uma opção de montagem de sistema de arquivos "wxallowed", que permitia que a memória fosse usada simultaneamente para escrita e execução, caso o executável ELF o arquivo é marcado com o marcador “wxneeded” e os próprios aplicativos foram protegidos adicionalmente por mecanismos и para limitar a lista de chamadas do sistema usadas e partes do sistema de arquivos disponíveis para o aplicativo, respectivamente.
Para complicar ainda mais a exploração de vulnerabilidades em tais aplicações, é proposto um acréscimo ao mecanismo , que verifica se a chamada do sistema está sendo executada a partir de uma página de memória gravável. Se a página for gravável, o processo será forçado a terminar. Dessa forma, um invasor não será capaz de explorar as chamadas do sistema e será forçado a tentar encontrar os gadgets necessários na implementação do JIT ou até mesmo fazer o trabalho mais difícil de detectar stubs de chamadas do sistema diretamente dentro do JIT. .
Os processos do Chrome/Iridium já são protegidos de forma bastante confiável usando promessa e revelação, mas remover a capacidade de usar, por exemplo, a chamada de sistema write(2) obviamente tem alguma vantagem, pois cria dificuldades adicionais para o invasor. No entanto, dificuldades também podem surgir se a implementação JIT usar chamadas de sistema nativas da memória W|X. No entanto, há motivos para esperar que não seja esse o caso, uma vez que a ABI foi alterada várias vezes, mas ninguém nunca relatou problemas.
As mudanças já estão disponíveis em snapshots regulares do branch OpenBSD-Current, todos os interessados estão convidados a testar.
Notícias relacionadas sobre a aparência do modo no Chrome/Iridium merecem um comentário separado de Theo . Do ponto de vista dele, isso é aceitável para alguns modelos de uso, mas provavelmente não para todos, já que esse modo obviamente aumentará a carga do processador. Atualmente, o Chrome funcionará principalmente se você desabilitar "wxallowed" para /usr/local, embora possa haver problemas com algumas extensões (ghostery é um exemplo). De uma forma ou de outra, Theo espera que o trabalho completo no modo JITless seja levado a um estado totalmente operacional em um futuro próximo.
Fonte: opennet.ru