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, uma confusão de tipos no Adobe Reader que leva a leitura fora dos limites e estouro de heap, com análise técnica e orientações de detecção. | Kitploit
Ferramentas/GitHubGitHub/tzwlhack/cve-2021-21017
Forensia de MemóriaAnálise de VulnerabilidadesExploraçãoExploração de Aplicações WebAnálise de Binários
GitHubtzwlhack/cve-2021-21017

CVE-2021-21017

Prova de conceito de exploit para CVE-2021-21017, uma confusão de tipos no Adobe Reader que leva a leitura fora dos limites e estouro de heap, com análise técnica e orientações de detecção.

Ver Repositório
há 4 anosAinda não revisado

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 no Adobe Reader :)

root@kitploit:~
# Plugin IA32, 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 relativa ao baseURL de um documento PDF para ser usada por APIs como: app.launchURL, document.submitForm ou app.media.createPlayer, se o baseURL aparentar ser uma string UTF-16BE, a 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 (Out-of-bounds read) 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, é claro, não é suficiente se ocorrer uma leitura fora dos limites. (string + o terminador NULL preenchendo um chunk inteiro do heap).

O que isso significa?

Type confusion => Leitura fora dos limites => Heap overflow => BUKAKE COMPLETO!

PoC Anexado

Na maioria das vezes resultará em um crash e, ocasionalmente, na sobrescrita do byteLength de um ArrayBuffer para 0xFF.

Se você tiver dúvidas, sinta-se à vontade para me contatar no twitter: https://twitter.com/Zeusb0x

Detecção

O catálogo do documento PDF terá uma entrada URI contendo 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 sem privilégios. Tentar fazer isso a partir do JavaScript lançará uma exceção de segurança.

Baixar ferramenta