highandhigh/cve-2015-0057Análise técnica detalhada e implementação de exploit para CVE-2015-0057, uma vulnerabilidade de use-after-free no win32k.sys, cobrindo sistemas Windows de 32 e 64 bits do XP ao 8.1.
Autor: Aaron Adams
Tradução: 55-AA
Nota do tradutor: algumas partes deste artigo foram traduzidas livremente; em caso de dúvida, consulte o original.
Terminologia:
No início deste ano, entrei em contato com uma vulnerabilidade interessante no win32k.sys (CVE-2015-0057) e implementei sua exploração estável em sistemas de 32 e 64 bits, variando do XP ao Windows 8.1 (com algumas exceções). Este artigo descreve em detalhes como concluí a exploração nessas duas plataformas; o final também traz algumas coisas extras. Além disso, descreve como realizar a exploração com privilégios de baixa integridade no Windows 8.1 com SMEP habilitado.
Este artigo é longo. Eu me esforcei para fornecer o máximo de detalhes possível, mostrando a complexidade de explorar essa vulnerabilidade em vez de escondê-la; naturalmente, também omiti alguns detalhes. Espero que estas informações sejam úteis para todos.
Em 10 de fevereiro de 2015, a Microsoft divulgou os detalhes do MS15-010. Esse bug foi descoberto primeiramente por Udi Yavo, da enSilo. Udi fez uma excelente análise no breaking malware blog, "one bit rule-bypassing windows 10 protections using single bit". Recomendo uma leitura atenta desse artigo para entender o bug a fundo, embora eu vá fornecer aqui o máximo de detalhes possível sobre os obstáculos que precisam ser superados ao acionar a vulnerabilidade. A exploração dessa vulnerabilidade é muito interessante; muitos detalhes vêm do blog do Udi. Segue a declaração dele:
Divulgação responsável: embora este blog seja técnico, não revelaremos nenhum código nem detalhes completos, para impedir que qualquer técnico especialista reproduza essa exploração.
Como recompensa extra por explorar essa vulnerabilidade, tivemos uma evolução Pokémon: um gênio técnico. Acho que devo dar crédito ao Udi por ter descoberto o bug e por ter disponibilizado no blog as circunstâncias e os detalhes para explorá-lo — essas informações foram extremamente úteis.
Antes, eu nunca havia explorado uma vulnerabilidade no win32k.sys nem estava familiarizado com callbacks em modo usuário e muitas das APIs relacionadas. Por isso, também agradeço a alguns pesquisadores de segurança renomados pelos recursos inovadores que disponibilizaram on-line, como Skywing, Tarjei Mandt, Alex Ionescu e j00ru. Todas essas pessoas disponibilizaram uma quantidade enorme de informações técnicas e merecem reconhecimento. Minha principal referência foi o artigo de Tarjei Mandt, Win32k.sys exploitation paper.
Enquanto escrevia esta exploração, um excelente engenheiro reverso implementou a exploração estável do CVE-2015-1701; o código de exemplo sobre callbacks em modo usuário foi muito útil. Agradeço ao autor.
Vale notar que minha análise foi feita no Windows 7, pois parece ser a única versão em que todas as estruturas do win32k.sys possuem símbolos correspondentes. A maioria desses símbolos também se aplica às estruturas de outras versões do Win32k.sys. Por alguma razão, a Microsoft removeu esses símbolos a partir do Windows 8.
Por fim, gostaria de dizer que meu método de exploração é bastante complexo. É perfeitamente possível que exista uma forma mais simples que eu não tenha encontrado. Gostaria muito de ouvir se alguém usou um método diferente. De todo modo, espero que tudo isso seja útil para pesquisas sobre vulnerabilidades no win32k.sys.
Abaixo, vemos o bug na desmontagem do win32k!xxxEnableWndSBArrows. É um bug bastante sutil:
Situação sem patch:
.text:FFFFF97FFF1B157D mov r8d, r13d
.text:FFFFF97FFF1B1580 mov rdx, r14
.text:FFFFF97FFF1B1583 call xxxDrawScrollBar ; 触发usermode callback
.text:FFFFF97FFF1B1588 jmp short loc_FFFFF97FFF1B1519
[...]
.text:FFFFF97FFF1B1519 mov eax, [rbx] ; 引用 tagSBINFO 指针而没有经过检查
.text:FFFFF97FFF1B151B mov ebp, 0FFFFFFFBh
.text:FFFFF97FFF1B1520 xor eax, esi
No código acima, Win32K!xxxdrawscrollbar pode, quando apropriado, fazer callback para o espaço do usuário. No código do modo usuário, o ponteiro para tagSBINFO pode ser liberado pelo atacante. Ao retornar ao código acima, a instrução em 0xFFFFF97FFF1B1519 fará referência a um ponteiro inválido.
Situação com patch:
.text:FFFFF97FFF1D69C3 xor r8d, r8d
.text:FFFFF97FFF1D69C6 mov rdx, rbp
.text:FFFFF97FFF1D69C9 call xxxDrawScrollBar ; 触发usermode callback
.text:FFFFF97FFF1D69CE cmp rbx, [rdi+0B0h] ; 检查 tagSBINFO 指针是否正确
---.text:FFFFF97FFF1D69D5 jz short loc_FFFFF97FFF1D69E4; 如果正确则继续原来的流程
| .text:FFFFF97FFF1D69D7 mov rcx, rbp
| .text:FFFFF97FFF1D69DA call _ReleaseDC
| .text:FFFFF97FFF1D69DF jmp loc_FFFFF97FFF1D6958 ; 跳转到函数退出
|->.text:FFFFF97FFF1D69E4 mov eax, [rbx] ; 放心地使用正确的 tagSBINFO 指针
.text:FFFFF97FFF1D69E6 xor eax, r14d
Na versão corrigida acima, vemos que é feita uma verificação antes de usar o ponteiro tagSBINFO. As informações relacionadas à estrutura serão fornecidas mais adiante.
Ao implementar esta exploração, realizamos diversas corrupções. E foi durante uma dessas corrupções que acionamos a vulnerabilidade.
A causa técnica desse bug é um use-after-free (UAF) no heap da área de trabalho (desktop heap). No começo, isso me confundiu bastante, pois eu não conhecia o mecanismo de callbacks em modo usuário do win32k.sys nem como ele funcionava. Por isso, pensei que fosse uma condição de corrida com locks que causava o UAF. Na verdade, o lock da estrutura é usado corretamente, e o fluxo é exatamente o esperado. Em resumo, o verdadeiro problema é:
É só isso. Sem considerar os callbacks em modo usuário, essa fase é bastante direta.
Mas como fazemos a corrupção e por quê? Como mencionado no blog do Udi, é possível definir ou limpar 2 bits em um local que o código do sistema trata como o campo WSBflags na estrutura tagSBINFO. Essa não é uma abordagem tradicional de exploração de UAF, mas o artigo dá uma dica de como fazer isso, e explicarei nas próximas seções. Primeiro, vamos entender como manipulamos e controlamos esses bits.
Estrutura tagSBINFO (idêntica em 32 e 64 bits):