
PoC for Foxit Reader CVE-2018-14442
PDF é um formato de arquivo usado para representar documentos. Um pdf é composto por múltiplos objetos de dados
Objetos Primitivos Simples Inteiro, Número, Booleano, Nulo
Objetos Complexos
| Formato | Nome |
|---|---|
| [.*] | Array |
| (.*) | String |
| <<.*>> | Dictionary |
| <.*> | Hex String |
| /.* | Nome |
| stream.*endstream | Fluxo |
Esses objetos definem como um pdf se parece e o que ele contém. As estruturas em pdf estão presentes em 2 tipos de objetos - Diretos e Indiretos. Um objeto indireto começa com o número do objeto e o número de geração, seguido pelo objeto real. Objetos Indiretos podem ser referenciados diretamente em outros objetos como n m R onde n e m são os números do objeto e da geração, respectivamente.
Objetos dicionário são os blocos básicos de construção do documento. Existem alguns objetos de dicionário gerais necessários para formar a página ou o próprio documento. O mais importante é o dicionário Root que define links para todos os outros Pages, Metadata, Names, etc., cada um dos quais pode ser algum outro objeto.
Objetos de fluxo contêm a maior parte dos dados binários, como fontes, imagens ou dados comprimidos/criptografados.
Um documento PDF pode ser criptografado para proteger seu conteúdo contra acesso não autorizado. A criptografia se aplica a todas as strings e fluxos no arquivo PDF do documento, com algumas exceções, como o próprio dicionário Encrypt. A criptografia se aplica principalmente a objetos de fluxo. A criptografia não é aplicada a outros tipos de objeto, como inteiros e valores booleanos, que são usados principalmente para transmitir informações sobre a estrutura do documento, e não sobre seu conteúdo.
As informações relacionadas à criptografia devem ser armazenadas no dicionário de criptografia do documento, que deve ser o valor da entrada "Encrypt" no dicionário trailer do documento.
CPDF_Parser::StartParse define m_pCryptoHandler para objetos indiretos de um pdf que estão criptografados. m_pCryptoHandler deve ser anulado quando CPDF_Parser::ReleaseEncryptHandler for concluído. Em vez disso, CPDF_Parser::ReleaseEncryptHandler não remove a referência ao CryptoHandler em CPDF_Parser e fica pendente.
Mais tarde, quando o analisador começa a analisar os objetos referenciados no dicionário Root, m_pCryptoHandler+8 é chamado para descriptografar os dados.
Um bug semelhante foi corrigido no pdfium no commit 741c362fb75fd8acd2ed2059c6e3e716a63a7ac8. Veja https://bugs.chromium.org/p/chromium/issues/detail?id=726503
Os PDFs permitem incorporar JS no documento que pode ser executado automaticamente se inserido em OpenAction de um dicionário do tipo Catalog. Uma vez que temos execução de JS, podemos fazer heap spray de objetos no espaço do processo para chegar a um endereço previsível onde escreveremos nossa cadeia ROP.
Quando um documento PDF é assinado no Foxit Reader, ele usa plugins\jrsys\x86\jrsysMSCryptoDll.dll do diretório de instalação para ler as informações assinadas, que carrega jrsysCryptoDll.dll em um endereço estático de 0x10000000. Esta dll importa VirtualAlloc, o que facilita a execução do payload. O exploit anexado usa heap spraying para obter um layout de memória previsível e usa uma cadeia ROP para alocar uma página RWX, copiar e executar o payload.
Este exploit foi testado usando Foxit Reader 9.0.1.1049 x86 executando no MS Windows 7 Enterprise Build 7601 SP1 x86. O exploit requer que o heap esteja em um estado específico; se o exploit falhar, tente novamente. Consulte a demonstração em vídeo. Esta vulnerabilidade também está presente no Foxit PDF Reader and Converter para Android.
bitcoins.pdf é o pdf criado que faz a realocação da memória liberada e aciona o bug central. Se você deseja reproduzir a falha no depurador, ative Page Heaps para FoxitReader.exe e abra bitcoins.pdf.
Esta falha foi encontrada por Cloudfuzz - Uma plataforma de fuzzing desenvolvida na Payatu. Análise adicional e exploração foram feitas por Sudhakar