Pufferüberlauf.

Pufferüberläufe entstehen, wenn Eingabelängen in Sprachen wie C und C++ nicht ordnungsgemäß gegen die Größe des Zielpuffers begrenzt werden. Die überschüssigen Bytes überschreiben benachbarte Stack-Frames, Heap-Chunks, Funktionspointer oder Rücksprungadressen und ermöglichen es Angreifern, den Kontrollfluss zu kapern oder Daten abzuziehen. Ein klassischer Stack Smash überschreibt die gespeicherte Rücksprungadresse, sodass die Funktion in einen vom Angreifer eingeschleusten Shellcode "zurückkehrt"; Heap-Überläufe hingegen korrumpieren Allocator-Metadaten oder benachbarte Objekte, um ein Schreib-Primitiv zu erlangen.

Dieses Muster hat die Geschichte des Internets geprägt. Der Morris Worm von 1988 verbreitete sich über einen Stack-Überlauf in BSD fingerd; Code Red (2001) missbrauchte einen ungeprüften Puffer im IIS-.ida-ISAPI-Filter (CVE-2001-0500); und SQL Slammer (2003) nutzte den Überlauf im SQL Server Resolution Service (MS02-039 / CVE-2002-0649) aus und infizierte mit einem einzigen 404-Byte-UDP-Paket an Port 1434 innerhalb von zehn Minuten rund 75.000 Hosts — sechs Monate nachdem der Patch ausgeliefert worden war.

Out-of-Bounds-Write (CWE-787) belegte 2024 Platz 2 der CWE Top 25, nur hinter XSS. Moderne Gegenmaßnahmen kombinieren Stack-Canaries, ASLR, DEP/NX, Control-Flow Integrity (Intel CET, ARM PAC/BTI), sicherere libc-Funktionen, Compiler-Härtung (_FORTIFY_SOURCE), Fuzz-Testing und — zunehmend — die Portierung von kritischem Code in speichersichere Sprachen wie Rust.

flowchart TD
  A[Angreifer sendet überdimensionierte Eingabe] --> B{Länge gegen<br/>Puffergröße geprüft?}
  B -->|Ja, begrenzt| C[Eingabe gekürzt / abgelehnt]
  B -->|Keine Längenprüfung| D[Schreiben über Pufferende hinaus]
  D --> E[Rücksprungadresse oder<br/>Funktionspointer überschreiben]
  E --> F[Kontrollfluss umgeleitet]
  F --> G[Angreifer-Shellcode / ROP-Kette läuft]
  C --> H[Programm läuft sicher weiter]