Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2021-21017 — Proof-of-Concept-Exploit für CVE-2021-21017: Typverwechslung in Adobe Reader, die über eine manipulierte PDF-baseURL mit UTF-16BE/ANSI-Inkonsistenz zu einem Heap-Überlauf führt. | Kitploit
Tools/GitHubGitHub/zeusbox/cve-2021-21017
SpeicherforensikSchwachstellenanalyseExploitationWebanwendungs-ExploitationFuzzingBinary-Exploitation
GitHubzeusbox/cve-2021-21017

CVE-2021-21017

Proof-of-Concept-Exploit für CVE-2021-21017: Typverwechslung in Adobe Reader, die über eine manipulierte PDF-baseURL mit UTF-16BE/ANSI-Inkonsistenz zu einem Heap-Überlauf führt.

Repository anzeigen
4412vor 5 JahrenVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

CVE-2021-21017

Nicht schon wieder ein Adobe Reader Byte Order Mark Fehler :)

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;
  }
  .............................................................
  .............................................................
}

Beim Erstellen einer absoluten URL aus einer relativen URL relativ zum baseURL eines PDF-Dokuments, die von APIs wie app.launchURL, document.submitForm oder app.media.createPlayer verwendet wird: Wenn die baseURL wie ein UTF-16BE-String aussieht, wird auch der relative String bei der Verkettung als UTF-16BE-String behandelt, obwohl es sich tatsächlich um einen ANSI-String handelt.

Dies kann einerseits zu einem Out-of-bounds-Lesezugriff führen. Andererseits wird bei der Speicherzuweisung für den Zielpuffer die relative URL als ANSI-String "gemessen". Dies ist natürlich nicht ausreichend, wenn ein Out-of-bounds-Lesen auftritt. (String + der NULL-Terminator füllt einen ganzen Heap-Chunk).

Was bedeutet das?

Typverwechslung => Out-of-bounds-Lesen => Heap-Überlauf => FULL BUKAKE!

PoC beigefügt

Es führt meistens zu einem Absturz und gelegentlich zum Überschreiben der byteLength eines ArrayBuffers auf 0xFF.

Bei Fragen können Sie mich gerne auf Twitter kontaktieren: https://twitter.com/Zeusb0x

Erkennung

Das PDF-Dokumentkatalog wird einen URI-Eintrag haben, der eine indirekte Referenz auf ein Dictionary-Objekt enthält. Dieses wiederum hat einen Base-Eintrag, der die eigentliche baseURL ist. Diese wird höchstwahrscheinlich in hexadezimaler Notation vorliegen und mit den Zeichen \xFE\xFF beginnen. (siehe PoC). Glücklicherweise ist dies die einzige Möglichkeit, die baseURL eines Dokuments in einem normalen, nicht privilegierten Kontext zu ändern. Der Versuch, dies über JavaScript zu tun, löst eine Sicherheitsausnahme aus.

Tool herunterladen