Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
CVE-2021-21017 — Prova de conceito de exploit para CVE-2021-21017: confusão de tipo no Adobe Reader levando a estouro de heap via PDF manipulado com baseURL e incompatibilidade UTF-16BE/ANSI. | Kitploit
Ferramentas/GitHubGitHub/zeusbox/cve-2021-21017
Forensia de MemóriaAnálise de VulnerabilidadesExploraçãoExploração de Aplicações WebFuzzingExploração de Binários
GitHubzeusbox/cve-2021-21017

CVE-2021-21017

Prova de conceito de exploit para CVE-2021-21017: confusão de tipo no Adobe Reader levando a estouro de heap via PDF manipulado com baseURL e incompatibilidade UTF-16BE/ANSI.

Ver Repositório
4412há 5 anosRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

CVE-2021-21017

Mais um bug de Byte Order Mark do Adobe Reader :)

root@kitploit:~
# IA32 plugin, ver. 2020.013.20074.
char * __cdecl FUN_2581894c(char *base_url,LPCSTR rel_url)
{
  ............................................................
  ............................................................
  if ((base_url != (char *)0x0) && (rel_url != (LPCSTR)0x0)) {
    if ((*base_url == -2) && (base_url[1] == -1)) {
      iVar6 = bytes_len(base_url);
      pcVar7 = base_url + iVar6;
      pcVar8 = rel_url + 2;
      do {
        do {
          cVar3 = *pcVar8;
          pcVar1 = pcVar8 + 2;
          *pcVar7 = cVar3;
          pcVar2 = pcVar7 + 2;
          cVar4 = pcVar8[1];
          pcVar7[1] = cVar4;
          pcVar7 = pcVar2;
          pcVar8 = pcVar1;
        } while (cVar3 != '\0');
      } while (cVar4 != '\0');
    }
    else {
      lstrcatA(base_url,rel_url);
    }
    return base_url;
  }
  .............................................................
  .............................................................
}

Ao construir uma URL absoluta a partir de uma URL relativa ao baseURL de um documento PDF para ser usada por APIs como: app.launchURL, document.submitForm ou app.media.createPlayer, se o baseURL parecer ser uma string UTF-16BE, a URL relativa também é tratada como uma string UTF-16BE ao realizar a concatenação, embora na verdade seja uma string ANSI.

Isso pode resultar em acesso de leitura fora dos limites por um lado. Por outro lado, ao alocar memória para armazenar o buffer de destino, a URL relativa é "medida" como uma string ANSI. Isso obviamente não é suficiente se ocorrer a leitura fora dos limites. (string + o terminador NULL preenchendo um chunk inteiro do heap).

O que isso significa?

Confusão de tipo => Leitura fora dos limites => Estouro de heap => FULL BUKAKE!

PoC Anexado

Na maioria das vezes resultará em uma falha e ocasionalmente em sobrescrever o byteLength de um ArrayBuffer para 0xFF.

Se você tiver perguntas, sinta-se à vontade para entrar em contato comigo no Twitter: https://twitter.com/Zeusb0x

Detecção

O catálogo do documento PDF terá uma entrada URI com uma referência indireta a um objeto dicionário. Este, por sua vez, terá uma entrada Base, que é o baseURL real. Provavelmente estará presente em notação hexadecimal e começará com os caracteres \xFE\xFF. (veja o PoC). Felizmente, esta é a única maneira de alterar o baseURL de um documento em um contexto normal e não privilegiado. Tentar fazer isso a partir do JavaScript gerará uma exceção de segurança.

Baixar ferramenta