O exploit foi testado no Windows RS5 de 64 bits e tem como alvo uma compilação personalizada do Firefox, então não se surpreenda se for necessário algum trabalho para fazê-lo funcionar em outro lugar :). No entanto, se você quiser apenas executar o exploit sem compilar nada, preparei um navegador empacotado que enviei em release/firefox-68.0a1.en-US.win64.7z. Ele também inclui o shell js.exe bem como informações de símbolos privados para js.exe, firefox.exe e xul.dll.

O processo de exploração funciona de forma muito semelhante ao meu exploit anterior kaizen.js como mencionado acima. Ele despacha a execução para o ReflectiveLoader de uma dll reflexiva que implementa o payload:

1. Se o payload detectar que foi invocado por js.exe, ele simplesmente envia PWN para stdout, abre uma calculadora e sai.
2. Se for executado a partir do navegador, ele começa se injetando em outros processos do Firefox.exe. Para conseguir isso, o exploit em Javascript passa um ponteiro para a cópia da dll reflexiva, e a dll reflexiva a mapeia nos outros processos. Uma vez feito isso, ele cria uma thread remota no carregador reflexivo e tira uma soneca. A razão para isso é que o exploit está bastante sujo em seu estado atual e não implementa continuidade de processo. Embora, a essa altura, eu não ache que seria muito trabalho. Talvez eu consiga fazer isso :-).
3. Quando o payload é executado a partir de outros Firefox.exe, ele faz inline-hook da função xul!nsJSUtils::ExecutionContext::Compile. Esta função é executada quando scripts precisam ser avaliados pelo mecanismo JavaScript; então isso pareceu um candidato bom o suficiente para o que eu queria fazer. A versão com hook simplesmente prefixa um payload JavaScript arbitrário de nossa escolha.
4. Quando o hook é colocado, ele simplesmente retorna. Neste ponto, as outras origens tiveram JavaScript arbitrário injetado nelas. O payload que uso é simplesmente mudar a imagem de fundo dessas origens pela imagem temática do Diary of a reverse-engineer, bem como redirecionar todos os links para o blog :).

Na realidade, há uma série de detalhes mais sutis que não são descritos acima e, se você estiver interessado, é convidado a encontrar a verdade e ler as fontes :).

Compilando o payload

Para compilar o payload, basta executar nmake a partir de um prompt do VS 2017 x64.

Isso cria um arquivo payload.dll / payload.pdb dentro do diretório payload\bin. Além disso, um arquivo JavaScript chamado payload.js que incorpora a dll dentro de um Uint8Array com o offset para o carregador.

Compilando o Firefox

Escrevi este exploit contra uma compilação local do Windows sincronizada com o seguinte id de revisão: 2abb636ad481768b7c88619080cf224b2c266b2d (se você não quiser compilar por conta própria, fiz upload da minha compilação aqui: release/firefox-68.0a1.en-US.win64.7z):

E usei o seguinte arquivo mozconfig:

Discussão

Embora tenha sido suficiente para o meu propósito, não tenho certeza se xul!nsJSUtils::ExecutionContext::Compile é a função perfeita para inserir scripts arbitrários. Tenho certeza de que gastar mais tempo entendendo um pouco como funciona o front-end do xul poderia levar a um ponto de hook melhor.

Alguns outros caminhos que descobri após escrever o exploit são discutidos nesta entrada do bugzilla: 982974 (System principal for the JavaScript interpreter and security.turn_off_all_security_so_that_viruses_can_take_over_this_computer). Seria interessante ver o quanto disso ainda é relevante para o Firefox hoje.

Talvez alguém já tenha pesquisado este assunto e eu tenha perdido completamente. De qualquer forma, fique à vontade para me contatar com qualquer feedback!

Outra coisa interessante seria explorar se há alguma maneira de ter um mecanismo de persistência no navegador. Não pesquisei essa área ainda, mas seria muito legal :).