Theo de Raad planos para reforçar o mecanismo de proteção de memória W^X (Write XOR Execute). A essência do mecanismo é que as páginas de memória de um processo não podem ser acessadas simultaneamente para gravação e execução. Assim, o código só pode ser executado após a proibição de gravação, e a gravação em uma página de memória só é possível após a proibição de execução. O mecanismo W^X ajuda a proteger aplicativos no espaço do usuário contra ataques típicos realizados através de estouro de buffer, incluindo estouros de pilha, e está ativo no OpenBSD. .
Desde o início do trabalho sobre o W^X, ficou claro que é um caminho longo, pois existe um número significativo de aplicativos que utilizam JIT. As implementações de JIT podem ser divididas em três categorias:
- Alternando a memória entre os estados W e X, aceitando o 'custo' da chamada de sistema. .
- Criando aliases entre um par de mapeamentos W e X da mesma memória.
- A variante mais 'suja' — requerendo um modelo de memória W|X, permitindo a execução e gravação simultâneas.
Atualmente, há significativamente menos programas usando a terceira variante e mais usando a primeira e a segunda. No entanto, como era necessário executar programas com JIT W|X (principalmente, Chromium e Iridium), foi adicionada a opção de montagem do sistema de arquivos 'wxallowed', que permitia o uso simultâneo da memória para gravação e execução, caso o arquivo ELF executável fosse marcado com o indicador 'wxneeded', e os próprios aplicativos fossem adicionais protegidos usando mecanismos e para restringir a lista de chamadas de sistema utilizadas e as partes do sistema de arquivos disponíveis para o aplicativo, respectivamente.
Para dificultar ainda mais a exploração de vulnerabilidades em tais aplicativos, foi proposta uma adição ao mecanismo , que verifica se a chamada de sistema está sendo executada a partir de uma página de memória disponível para gravação. Se a página estiver disponível para gravação, o processo é encerrado forçadamente. Assim, o invasor não conseguirá utilizar chamadas de sistema e será forçado a tentar encontrar os gadgets necessários na implementação JIT ou até mesmo realizar um trabalho mais difícil de detectar ganchos de chamadas de sistema diretamente dentro .
Os processos Chrome/Iridium são suficientemente protegidos através de pledge e unveil, mas a proibição de usar, por exemplo, a chamada de sistema write(2) claramente traz algumas vantagens, pois cria dificuldades adicionais para o atacante. No entanto, dificuldades também podem surgir se a implementação do JIT utilizar chamadas de sistema nativas a partir da memória W|X. Contudo, há razões para acreditar que não enfrentaremos tal situação, já que a ABI foi alterada várias vezes, mas ninguém nunca relatou problemas.
As mudanças já estão disponíveis nas versões regulares da ramificação OpenBSD-CURRENT, e todos os interessados são convidados a testá-las.
Comentários individuais foram feitos por Theo sobre as notícias relacionadas ao modo de funcionamento do Chrome/Iridium . De seu ponto de vista, isso é aceitável para alguns modelos de uso, mas provavelmente não para todos, já que este modo certamente aumentará a carga sobre o processador. Agora, o Chrome principalmente funcionará se o "wxallowed" for desativado para /usr/local, embora sejam prováveis problemas com algumas extensões (como, por exemplo, a ghostery). De qualquer forma, Theo espera que o funcionamento total no modo JITless seja aprimorado para um estado completamente operacional em breve.
Fonte: opennet.ru
