CVE-2021-21017

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

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

Wenn eine absolute URL aus einer relativen URL in Bezug auf die baseURL eines PDF-Dokuments für APIs wie app.launchURL, document.submitForm oder app.media.createPlayer erstellt wird, und die baseURL wie ein UTF-16BE-String aussieht, wird die relative URL bei der Verkettung ebenfalls als UTF-16BE-String behandelt, obwohl sie tatsächlich ein ANSI-String ist.

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 „vermessen". Das reicht natürlich nicht aus, wenn ein OOB-Read auftritt. (String plus der NULL-Terminator, der einen ganzen Heap-Chunk füllt).

Was bedeutet das?

Typverwechslung => Out-of-bounds-Read => Heap-Overflow => VOLLER BUKAKE!

PoC beigefügt

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

Wenn du Fragen hast, kannst du mich gerne auf Twitter kontaktieren: https://twitter.com/Zeusb0x

Erkennung

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