Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2021-21017 — Proof-of-concept exploit per CVE-2021-21017, una confusione di tipo in Adobe Reader che porta a una lettura fuori dai limiti e a un overflow dell'heap, con analisi tecnica e indicazioni di rilevamento. | Kitploit
Strumenti/GitHubGitHub/tzwlhack/cve-2021-21017
Memory ForensicsAnalisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebAnalisi di Binari
GitHubtzwlhack/cve-2021-21017

CVE-2021-21017

Proof-of-concept exploit per CVE-2021-21017, una confusione di tipo in Adobe Reader che porta a una lettura fuori dai limiti e a un overflow dell'heap, con analisi tecnica e indicazioni di rilevamento.

Vedi Repository
4 anni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

CVE-2021-21017

Non è un altro bug del Byte Order Mark di 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;
  }
  .............................................................
  .............................................................
}

Quando si costruisce un URL assoluto a partire da uno relativo al baseURL di un documento PDF, da utilizzare con API come: app.launchURL, document.submitForm o app.media.createPlayer, se il baseURL sembra essere una stringa UTF-16BE, anche quello relativo viene trattato come una stringa UTF-16BE durante la concatenazione, sebbene in realtà sia una stringa ANSI.

Questo può comportare, da un lato, un accesso in lettura fuori dai limiti (Out-of-bounds read). Dall'altro lato, quando si alloca memoria per contenere il buffer di destinazione, l'URL relativo viene "misurato" come una stringa ANSI. Questo ovviamente non è sufficiente se si verifica una lettura fuori dai limiti. (stringa + terminatore NULL che riempie un intero chunk dell'heap).

Cosa significa tutto ciò?

Type confusion => Lettura fuori dai limiti => Heap overflow => FULL BUKAKE!

PoC allegato

Il più delle volte provocherà un crash e occasionalmente la sovrascrittura del byteLength di un ArrayBuffer a 0xFF.

Se hai domande, non esitare a contattarmi su Twitter: https://twitter.com/Zeusb0x

Rilevamento

Il catalogo del documento PDF avrà una voce URI che contiene un riferimento indiretto a un oggetto dizionario. Questo, a sua volta, avrà una voce Base, che è il baseURL effettivo. Molto probabilmente sarà presente in notazione esadecimale e inizierà con i caratteri \xFE\xFF. (vedi PoC). Fortunatamente questo è l'unico modo per modificare il baseURL di un documento in un contesto normale e non privilegiato. Tentare di farlo da JavaScript genererà un'eccezione di sicurezza.

Scarica lo strumento