Use-After-Free.

Ein Use-After-Free (UAF) tritt auf, wenn ein Pointer ein Objekt weiter referenziert, nachdem free()/delete den Speicher freigegeben hat. Schafft es ein Angreifer, denselben Speicherbereich als anderes Objekt neu zu allokieren — eine Technik namens Heap Grooming oder „Heap Feng Shui" —, verschafft ihm der dangling Pointer faktisch eine Type-Confusion, ideal zum Überschreiben von Vtable-Pointern, Callback-Adressen oder sensiblem Zustand. UAFs dominieren die Browser- und Kernel-Exploitation und sind als CWE-416 katalogisiert.

Benannte Fälle verdeutlichen die Auswirkungen. CVE-2018-8174, ein UAF in der über den Internet Explorer erreichbaren VBScript-Engine, wurde im „Double Kill"-Zero-Day als Waffe eingesetzt und in Exploit-Kits integriert. CVE-2022-0609, ein UAF in der Animation-Komponente von Chrome, wurde als Zero-Day aktiv ausgenutzt; Googles Threat Analysis Group schrieb die Kampagnen nordkoreanischen Staatsakteuren zu, die Medien- und Fintech-Unternehmen ins Visier nahmen. Wegen der Häufigkeit solcher Fehler berichten sowohl Microsoft als auch Google, dass rund 70 % ihrer bisherigen CVEs auf Speicher-Sicherheitsfehler zurückgehen, was den Branchentrend hin zu Rust antreibt.

flowchart TD
  A[Objekt allokiert, Pointer P referenziert es] --> B["free() / delete aufgerufen"]
  B --> C[P zeigt jetzt ins Leere, Speicher an Allokator zurückgegeben]
  C --> D[Angreifer flutet den Heap, um den Slot zurückzugewinnen]
  D --> E[Speicher als angreiferkontrolliertes Objekt neu allokiert]
  E --> F[Programm dereferenziert P]
  F --> G[Type-Confusion -> Übernahme von Vtable / Kontrollfluss]

Abwehrmaßnahmen umfassen disziplinierte Besitzmodelle (RAII, Smart Pointers), Garbage-Collected- oder speichersichere Sprachen wie Rust, gehärtete Allokatoren (Quarantäne, Isolation Pools, GWP-ASan) sowie Tests mit KASAN/Valgrind. Browser setzen zudem MiraclePtr und PartitionAlloc-artige Schutzmechanismen ein.