erfze/cve-2017-0261CVE-2017-8570 Exp e análise de amostras de exploração
Causa: Ao abrir um documento do Office, o FLTLDR.EXE é usado para renderizar um arquivo EPS incorporado que contém a vulnerabilidade. O arquivo é escrito em linguagem PostScript e pode ser explorado pelo atacante através da operação "save-restore", sendo essencialmente uma vulnerabilidade de UAF (Use-After-Free). A vulnerabilidade pode ser explorada quando um usuário abre um arquivo contendo uma imagem gráfica malformada ou insere uma imagem gráfica malformada em um arquivo do Office.
Versões afetadas: Microsoft Office 2010 Service Pack 2, Microsoft Office 2013 Service Pack 1, Microsoft Office 2016
POC: GitHub de kcufId
O autor pesquisou por muito tempo na internet, mas não encontrou um pacote de instalação do Office que contivesse o EPSIMP32.FLT. Felizmente, o mestre kcufId forneceu um LoadEps.exe para carregar arquivos EPS, agradecimentos ao mestre kcufId.
O LoadEps.exe primeiro carrega o EPSIMP32.FLT:
Depois chama ImportGr para começar a carregar o arquivo EPS:
Aqui, pressione F7 para seguir e então interrompa com sucesso no ponto de interrupção definido dentro do EPSIMP32.FLT.
Antes de entrar no assunto principal, vamos primeiro explicar a estrutura do objeto PostScript.
// PostScript Object
struct PostScript object
{
dword type;
dword attr;
dword value1;
dword value2; // se for array, aponta para userdict onde o objeto array é armazenado
}ps_obj;
Os diferentes type correspondem aos seguintes valores:
0x0 nulltype
0x3 integertype
0x5 realtype
0x8 booleantype
0x10 operatortype
0x20 marktype
0x40 savetype
0x300 nametype
0x500 stringtype
0x900 filetype
0x30000 arraytype
0x0B0000 packedarraytype
0x70000 packedarraytype
0x110000 dicttype
0x210000 gstatetype
Tomando uma string como exemplo, explicamos sua estrutura de armazenamento. Definindo um ponto de interrupção na função forall, podemos ver como ela processa strings (como localizar a função forall, consulte https://paper.seebug.org/368/).
A imagem 1 corresponde a ps_obj, cujo campo value2 aponta para o item correspondente na lista de índices (imagem 2); o item de índice aponta para uma estrutura de tamanho 0x30, cujo offset 0x24 contém um ponteiro para um ponteiro para uma estrutura de tamanho 0x28 (imagem 5), e o offset 0x2C armazena o tamanho da string (imagem 3); na estrutura da imagem 5, o offset 0x4 armazena o endereço do item correspondente na lista de índices (ou seja, o endereço 0x01DB5E94 da imagem 4), o offset 0x20 aponta para o local final de armazenamento da string (imagem 6), e o offset 0x24 é o tamanho real da memória ocupada — tamanho da string + 1.
Estrutura de tamanho 0x30:
+0x0 dword
+0x4 dword
+0x8 dword
+0xc dword
+0x10 dword
+0x14 dword
+0x18 dword
+0x1c dword
+0x20 dword
+0x24 dword pp_struct // ponteiro para ponteiro para estrutura de tamanho 0x28
+0x28 dword
+0x2c dword size // tamanho real da string
Estrutura de tamanho 0x28 (para array, essa estrutura tem tamanho 0x2C, e offset 0x28 aponta para elementos do array, cada elemento sendo um ps_obj):
+0x0 dword
+0x4 dword // armazena o endereço do item correspondente na lista de índices
+0x8 dword
+0xc dword
+0x10 dword
+0x14 dword
+0x18 dword
+0x1c dword
+0x20 dword ptr_object // aponta para o local final de armazenamento da string
+0x24 dword size // tamanho real da memória ocupada, tamanho real da string + 1
Primeira ativação da vulnerabilidade:
Primeiro, o estado da VM é salvo na variável l62. Em seguida, para cada caractere na variável l63, é chamado o processo de tratamento l61 —>> l59 —>> l56. l62 restore restaura o estado anterior, liberando assim o espaço de memória alocado pela instrução /l62 save def para a variável l63, tornando-se um ponteiro pendente.
As variáveis l95-l99 determinam o fluxo subsequente e todos têm valor 0 (ou seja, 32 bits):
Segunda ativação da vulnerabilidade: primeiro, aloca um espaço de memória de tamanho 0x27 (que realmente ocupará 0x28) para armazenar l63:
Depois, l62 restore restaura o estado anterior, liberando o espaço de memória alocado para l63, tornando-se um ponteiro pendente. Em seguida, executa l100; o espaço de memória antes ocupado por l63 é agora usado para armazenar a estrutura 0x28 da string l102 (ou seja, l136) (isso explica por que l63 alocou 0x27 de tamanho de memória):
Obtém os valores nos offsets 0x4, 0x20 e 0x24 dessa estrutura:
Finalmente, modifica o conteúdo da string l136 (a imagem mostra apenas parte das modificações):
Essas modificações são cuidadosamente construídas e serão usadas na terceira ativação da vulnerabilidade.
Terceira ativação da vulnerabilidade: aloca um array contendo 0x37 elementos, e ao percorrer até o 0x34º elemento, executa l62 restore:
Após executar restore, a estrutura 0x30 do array é sobrescrita pelo conteúdo da string l193:
Assim, o objeto executado pelo último (0x36) processo forall torna-se a estrutura 0x30 da imagem acima, e obter seu 0x36º elemento leva à string cuidadosamente construída na segunda ativação da vulnerabilidade:
O elemento do array obtido é um array de tamanho 4, cujo primeiro elemento é uma string com endereço inicial 0 e tamanho 0x7FFFFFFF:
