Prova de conceito para CVE-2024-54756, uma vulnerabilidade que encontrei no motor de script ZScript do GZDoom.
Uma prova de conceito para uma vulnerabilidade de execução arbitrária de código que encontrei na funcionalidade ZScript do GZDoom (https://github.com/zdoom/gzdoom). Um atacante pode compartilhar um arquivo PK3 contendo um arquivo fonte ZScript malicioso e obter acesso ao PC da vítima.
Muito obrigado a Rachael e Agent Ash na equipe de desenvolvimento do GZDoom por suas respostas rápidas, e a eles e aos outros desenvolvedores do GZDoom por abordarem isso rapidamente!
Confirmado para funcionar nas versões 4.13.0 e 4.13.1, e provavelmente funciona em versões anteriores também. Cuidado com qualquer pessoa que lhe diga para fazer downgrade para a versão 4.13.1 ou inferior para poder jogar o WAD deles.
Este PoC funciona apenas no Linux, mas a vulnerabilidade provavelmente existe também no Windows. Não testado no ZDoom ou LZDoom, mas a vulnerabilidade pode existir também neles.
A vulnerabilidade foi divulgada aos desenvolvedores antes da publicação deste PoC e não deve mais estar presente na versão 4.13.2. Até onde sei, esta versão não inclui nenhuma mudança prática que quebre algo.
Este PoC é feito e lançado para fins educacionais, para que desenvolvedores de engines de jogos/script possam entender como vulnerabilidades podem surgir e para que jogadores possam entender como um mod de jogo malicioso pode se parecer. Não sou responsável por qualquer uso indevido deste PoC. Por favor, não use isso para comprometer os PCs de seus colegas jogadores; é ilegal (você não deveria precisar que eu lhe diga isso), e é especialmente uma atitude baixa assumir o controle do computador de alguém através de um videogame.
Para usar este PoC, baixe este repositório e crie um arquivo PK3 (que é na verdade um arquivo zip com a extensão .pk3) contendo zscript.zs e MAPINFO:
git clone https://github.com/Chainmanner/GZDoom-Arbitrary-Code-Execution-via-ZScript-PoC
cd GZDoom-Arbitrary-Code-Execution-via-ZScript-PoC
zip PoC.pk3 zscript.zs MAPINFO
O payload padrão é executar um reverse shell para localhost na porta 1337. Inicie o listener:
nc -nvlp 1337
Execute o PoC assim:
gzdoom -iwad <your-doom-or-freedoom-wad> -file PoC.pk3
Se funcionou, você agora deve ter um reverse shell para si mesmo.
Este PoC é apenas para Linux. Pode não funcionar na primeira tentativa; apenas tente novamente até funcionar.
NOTA: Este é meu primeiro writeup de exploit e ainda estou trabalhando em minha habilidade de fazer writeups de baixo nível. Além disso, fiz grande parte da minha depuração com GDB e, infelizmente, não tive a boa sensação de salvar alguns dumps de memória para ilustrar melhor minha explicação. Desculpe! Meu próximo writeup será melhor, prometo.
GZDoom é um source port de Doom projetado para desempenho e extensibilidade. Graças às suas poderosas características, muitos WADs, mods e até conversões totais comerciais incríveis foram feitos. Infelizmente, onde há complexidade, há oportunidade para vulnerabilidades, e neste caso havia duas presentes no mecanismo de script ZScript que permitiram que uma cadeia de exploração completa surgisse.
Este ataque derrota o ASLR e contorna a necessidade de derrotar stack canaries. Acho que o CFI do Clang ou shadow stacks não teriam ajudado aqui.
A primeira e mais importante vulnerabilidade estava em como arrays enormes eram tratados. Se você alocar um array pequeno o suficiente, a região de memória alocada tende a ser preenchida com zeros e está devidamente separada de outros objetos; nenhuma informação pode ser obtida da leitura de memória não inicializada, e nenhum objeto se sobrepõe ao array. No entanto, se você alocar um array enorme - digamos, 1073741823 palavras de 32 bits ou mais - você será capaz de ler e escrever até 4 GiB de memória potencialmente não inicializada a partir do ponto de partida do array, permitindo que o atacante modifique diretamente outros objetos e derrote o ASLR encontrando endereços com offsets conhecidos. Além disso, quaisquer outros arrays criados após este ponto se sobreporão ao enorme.
A segunda vulnerabilidade estava nas permissões do mapa de memória. Para um desempenho mais rápido, o código ZScript é compilado JIT para bytecode x86 ou x86-64 sempre que possível. Para que isso aconteça, o código deve ser escrito em uma região de memória, e essa região deve ser executável. No entanto, a regra W^X afirma que uma região deve ser ou gravável ou executável, mas não ambas. Se ambas forem aplicadas ao mesmo tempo (em vez de tornar a região gravável, escrever o código e depois torná-la executável e não gravável), então um atacante com uma primitiva de escrita arbitrária poderá escalá-la para uma execução arbitrária de código; eles podem escrever shellcode e pular para ele, por exemplo, modificando o endereço de retorno na pilha (assumindo que o atacante não tenha uma primitiva de execução arbitrária). Se você observar os mapeamentos de memória do GZDoom quando ele está em execução, pode ver várias regiões RWX:
7fcd19700000-7fcd19800000 rwxp 00000000 00:00 0
7fcd1a100000-7fcd1a200000 rwxp 00000000 00:00 0
7fcd1eb00000-7fcd1ec00000 rwxp 00000000 00:00 0
Portanto, se primitivas de escrita arbitrária e execução arbitrária estiverem disponíveis, e o atacante souber onde qualquer região RWX está presente, eles podem escrever shellcode arbitrário e executá-lo. Tornar essas regiões RW- ao escrever o código compilado JIT e depois R-X quando pronto para executar interromperia este PoC, mas não impediria um atacante de obter execução de código, por exemplo, modificando dados na pilha (ROP) ou heap.
Além disso, há um gadget útil. Lembra como ao alocar um array enorme, quaisquer outros arrays criados depois dele se sobrepõem? Isso inclui arrays de ponteiros de objetos. Assim como objetos C++, os objetos ZScript podem conter variáveis e ponteiros de função. Suponha que temos este objeto:
class WeirdObject
{
uint one;
uint two;
uint three;
uint four;
Function<clearscope void()> funcptr;
}
Se criarmos um array contendo um ponteiro para uma instância de WeirdObject, então o atacante pode mudar o ponteiro para onde quiser usando o array enorme e alterar os dados apontados acessando os campos do objeto, nos dando uma primitiva de leitura/escrita arbitrária indo além do heap. Ponteiros em ZScript são verificados para garantir que não sejam nulos, mas não para garantir que sejam válidos.
A presença de um ponteiro de função também nos dá uma primitiva de execução arbitrária; isso, no entanto, é um pouco menos direto, exigindo a criação de um VMFunction falso para satisfazer a máquina virtual. Assim que uma chamada a uma função ZScript é introduzida no código do exploit, esse código não é mais compilado JIT. Ainda funciona, mas se torna um pouco mais complicado de depurar e explorar. Pode haver uma maneira melhor de fazer esta parte, mas não estudei os internos do GZDoom suficientemente bem para conhecê-la.
Uma coisa a notar: WeirdObject tem variáveis membro herdadas, então o primeiro membro começa no offset 0x28.
Então agora, temos as seguintes ferramentas:
Como as encadeamos para fazer um exploit?