Proteções aprimoradas da memória no IE10
O Internet Explorer 10 apresenta grandes aperfeiçoamentos nas proteções da memória para dificultar a exploração das vulnerabilidades, ajudando a manter os usuários seguros na Web às vezes hostil. Esses aperfeiçoamentos aumentarão a dificuldade e o custo do desenvolvimento das explorações, dificultando a vida dos malfeitores.
Se o malware criado por engenharia social é a principal maneira que os malfeitores encontram de colocar código nos computadores das vítimas, isso se deve em grande parte ao fato de as vulnerabilidades dos navegadores terem se tornado menos comuns e mais difíceis de serem exploradas nos últimos anos. Entretanto, como cada vez mais usuários têm atualizado o navegador para o IE9 e se beneficiado da proteção oferecida pelo Filtro SmartScreen, os malfeitores voltaram a querer atacar o navegador e seus complementos.
Na postagem de hoje, descrevo o ambiente de riscos, examino as proteções existentes disponíveis no IE9 e explico como as novas proteções da memória do IE10 oferecem ainda mais segurança.
Ataque a navegadores da Web
O objetivo de um invasor ao explorar uma vulnerabilidade da memória é desviar o caminho de execução do código do navegador para um código de escolha do malfeitor. O invasor precisa de duas coisas para conseguir isso. Ele precisa ter o código disponível no computador da vítima. As técnicas usadas para obter esse código podem ser divididas em dois grupos. O invasor pode colocar seu próprio código mal-intencionado na memória usando técnicas como o heap spraying. Ou também pode selecionar um código já presente na memória usando uma técnica chamada Return Oriented Programming.
O invasor também precisa poder explorar uma vulnerabilidade que permita alterar a estrutura do fluxo da execução do código, como o estouro de buffer. Dessa forma, ele pode desviar o caminho do código para o endereço do código que ele deseja executar.
Em um ataque de estouro de buffer típico, um conjunto de dados criado cuidadosamente é colocado na pilha do thread, estourando seu buffer designado e substituindo outras estruturas de dados. Os invasores tentam substituir estruturas como registros de manipulador de exceção ou o endereço do remetente da função, o que lhes permite alterar o fluxo do código para um local escolhido na memória.
Outros tipos de ataques incluem vulnerabilidades do tipo "use-after-free", em que o aplicativo é levado a acessar um objeto liberado cuja memória já foi reutilizada para alguma outra finalidade.
Defendendo o navegador
As tecnologias de proteção da memória oferecem uma linha externa de defesa para impedir que os invasores atinjam seus objetivos. Essas tecnologias existem para tornar a exploração das vulnerabilidades mais difícil, menos confiável e, em alguns casos, impossível. As proteções da memória visam terminar, de forma segura, o processo de um navegador sob ataque antes que uma vulnerabilidade possa ser explorada com êxito para executar o código do invasor. Em muitos casos, com as proteções, os fornecedores ganham tempo para produzir e distribuir uma correção antes que uma vulnerabilidade seja explorada para causar danos.
As tecnologias de mitigação da memória empregadas pelo Internet Explorer evoluíram com o tempo para ajudar na defesa contra novas técnicas de ataque, à medida que se desenvolvem e popularizam. Muitas proteções, como o sinalizador compilador /GS, foram usadas por versões anteriores do Internet Explorer, mas são atualizadas e aperfeiçoadas periodicamente. Algumas proteções, como o ForceASLR (descrito a seguir), são novas no IE10 e se baseiam em novos recursos do sistema operacional.
Mitigações no tempo de compilação
As mitigações de compiladores estão disponíveis para os desenvolvedores de software e devem ser aplicadas como prática recomendada de desenvolvimento. A equipe do Internet Explorer inclui essas mitigações durante o desenvolvimento do Internet Explorer como requisito do nosso SDL (Ciclo de vida de desenvolvimento de segurança). Incentivamos os desenvolvedores de software a adotar seu próprio processo de SDL, que inclui a implementação dessas mitigações no tempo de compilação.
O sinalizador /GS foi introduzido no Visual Studio .NET 2002 e é usado por todas as versões do IE com suporte. Trata-se de uma tecnologia de compilador que adiciona um recurso de detecção de transbordamento de buffer à pilha do aplicativo. Segredos de segurança conhecidos como "canários" são adicionados aos limites da pilha do aplicativo no tempo de execução. Por exemplo, um canário colocado entre o buffer de uma pilha e um endereço do remetente será substituído por um ataque de estouro de buffer que tenha como alvo o endereço do remetente. Isso permite que o processo detecte a ocorrência de um estouro. Uma exceção será acionada e o processo poderá ser terminado com segurança antes da execução do código do invasor.
Esse conceito básico de proteção foi aperfeiçoado em cada nova versão do Visual Studio. A última versão do /GS aperfeiçoada, usada pelo Internet Explorer 9+, inclui heurísticas muito aprimoradas para proteger mais funções, incluindo matrizes Non-Pointer e estruturas de dados puras. Além disso, a otimização aperfeiçoada eliminou verificações desnecessárias, aumentando o desempenho da proteção.
O sinalizador /SAFESEH é uma opção de vinculador que oferece um mecanismo para que os manipuladores de exceção registrados de um aplicativo sejam armazenados em uma tabela de pesquisa em um local seguro da memória. No caso de uma exceção, os endereços do manipulador de exceção na pilha do aplicativo são validados em relação à tabela de pesquisa. Se os valores não corresponderem, o processo será terminado.
Um problema do sinalizador /SAFESEH é o fato de ele exigir que todos os módulos DLL aceitem a proteção para proteger o processo de forma confiável. Se algum módulo não aceitar, a proteção se tornará menos eficiente. Enquanto o SDL exige que todos os códigos da Microsoft sejam compilados com o SAFESEH, complementos de terceiros podem não ser compilados com o sinalizador.
O sinalizador /DYNAMICBASE é uma opção de vinculador que aceita um aplicativo na mitigação do sistema operacional conhecido como ASLR (Address Space Layout Randomization) , discutido com mais detalhes mais adiante nesta postagem.
Assim como a limitação do /SAFESEH, um problema do sinalizador /DYNAMICBASE é que a não aceitação dessa proteção por um módulo DLL prejudica o ASLR como mitigação da exploração. Qualquer módulo em um local previsível pode se tornar alvo de um invasor, e basta apenas um desses alvos previsíveis para haver uma exploração. Muitas explorações recentes atingem complementos de navegador que não aceitam a proteção do ASLR. Por exemplo, a exploração 0-day do Acrobat e Adobe Reader no ano passado se valeu de um local previsível das funções dentro de um módulo chamado icucnv36.dll que não aceitou o ASLR.
Mitigações no tempo de execução
As mitigações no tempo de execução permitem que o sistema operacional ajude a manter o processo protegido.
O DEP/NX é uma mitigação de sistema operacional que se baseia em recursos de segurança essenciais (Prevenção de Execução de Dados ou No eXecute) de CPUs modernas. Essa mitigação permite que páginas da memória sejam marcadas como não executáveis (dados); o processador se recusará a executar código em uma página da memória com essa marca.
No segundo estágio da exploração de uma memória, o invasor poderá tentar executar seu próprio código, já adicionado por ele a uma página de dados da memória. Se a página de dados tiver sido marcada como não executável, o código do invasor não será executado e o processo será terminado de forma segura.
O suporte a DEP/NX foi habilitado por padrão pela primeira vez no IE8 e continua habilitado no IE10.
O SEHOP é uma mitigação no tempo de execução que oferece um mecanismo de proteção contra adulteração de manipulador de exceção muito parecida com o sinalizador compilador /SAFESEH. Essa proteção ocorre pela inserção de um registro de exceção simbólico como o registro da parte final na lista do manipulador de exceção do thread. Em caso de exceção, a lista do manipulador de exceção é percorrida para garantir que o registro simbólico seja alcançado. Se ele não puder ser alcançado, isso indica que a cadeia do manipulador de exceção está corrompida e o processo será terminado com segurança. Diferentemente do SafeSEH, o SEHOP não exige aceitação por parte de cada módulo individual, portanto, ele oferece proteção mesmo no caso de os complementos não terem sido compilados com os sinalizadores mais seguros.
O SEHOP foi habilitado pela primeira vez no IE9 e continua habilitado no IE10.
O Address Space Layout Randomization foi introduzido no Windows Vista e foi muito aperfeiçoado no Windows 8. O ASLR atribui aos aplicativos um endereço de memória com base aleatória quando eles são carregados pela primeira vez na memória. Além disso, outras estruturas da memória, como PEBs (Process Environment Blocks), Thread Environment Blocks, pilhas e heaps também são atribuídos a locais aleatórios da memória.
A randomização do local dos objetos e funções na memória ajuda a impedir que um invasor descubra onde eles estão, o que ajuda a evitar a técnica chamada Return Oriented Programming. Podemos pensar nessa randomização como se protegêssemos a carga do invasor com um cadeado de código. Não sabendo o código, o invasor tem somente uma chance de adivinhar. Se não conseguir adivinhar, o ataque será impedido, e o processo será terminado de forma segura.
A ilustração a seguir mostra como componentes básicos do sistema são carregados em endereços de memória aleatórios na inicialização do sistema.
O ASLR passou por vários aperfeiçoamentos no Windows 8, sendo todos eles utilizados pelo Internet Explorer 10.
Todas as alocações Ascendentes e Descendentes agora são randomizadas com o uso de 8 bits de entropia. Esse aperfeiçoamento reduz, de forma significativa, as regiões previsíveis da memória, incluindo VirtualAlloc e MapViewOfFile.
O HEASLR (High Entropy Address Space Layout Randomization) usufrui do aumento no espaço de endereçamento de 64 bits e atribui mais bits à entropia. Isso aumenta enormemente o número de possíveis endereços que podem ser atribuídos a um processo de 64 bits. Todos os processos de 64 bits podem aceitar a entropia aumentada disponibilizada pelo HEASLR. Os processos podem aceitar tanto no tempo de vinculação (/HIGHENTROPYVA) quanto no tempo de carregamento por meio de uma nova opção de execução do arquivo de imagem.
Por padrão, o navegador estilo Metro é executado no modo de 64 bits em computadores de 64 bits, oferecendo um espaço de endereçamento muito maior e, portanto, mais layout de memória aleatória.
O ForceASLR é sem dúvida a alteração mais importante do ASLR no Windows 8. O ForceASLR é uma nova opção de carregador usada pelo Internet Explorer 10 para instruir o sistema operacional a randomizar a localização de todos os módulos carregados pelo navegador, mesmo se algum módulo não tiver sido compilado pelo sinalizador /DYNAMICBASE. A proteção ForceASLR foi adicionada ao kernel do Windows 8, e o recurso agora está disponível como uma atualização para o Windows 7 que será instalada quando o Internet Explorer for instalado nessa plataforma.
Para ajudar a garantir a compatibilidade com esse recurso, e para oferecer a proteção por randomização da memória para versões anteriores do Internet Explorer que não dão suporte ao ForceASLR, continuamos recomendando aos desenvolvedores de complementos que usem o sinalizador /DYNAMICBASE.
Resumo
Espero que essa pequena visão geral das proteções da memória presentes no Windows 8 e no Internet Explorer 10 tenha sido valiosa. Nos bastidores, fizemos vários outros ajustes para aumentar a segurança, mas muitos deles são tão herméticos que nem temos como mencioná-los. Faremos mais alguns comunicados relacionados à segurança, portanto, fique atento às atualizações, enquanto continuamos a nossa missão de oferecer uma plataforma de navegação na Web segura.
—Forbes Higman, gerente de programas de segurança, Internet Explorer