Buffer-Overflow

Was ist ein Buffer-Overflow?

Ein Buffer-Overflow (auch: Pufferüberlauf) ist eine oft anzutreffende Quelle von Angriffspunkten in Programmen. Die Ursache ist eine fehlerhafte Behandlung von Eingaben und deren Länge.

Ein Puffer für Anmeldedaten kann beispielsweise so ausgelegt sein, dass er Eingaben von 12 Byte für den Benutzernamen verarbeiten kann. Wenn eine Eingabe eine Länge von 15 Byte umfasst, also 3 Byte mehr als erwartet, schreibt das Programm die überschüssigen Daten möglicherweise über die Puffergrenze hinaus.

In den überschriebene Speicherbereichen hätten normalerweise Prozessorbefehle, bestimmte Daten oder Adressen stehen sollen – was somit üblicherweise zu einem Absturz oder zumindest unerwünschtem Verhalten führt.

Buffer-Overflow-Angriff

Wird der Eingabestrom aber entsprechend gestaltet, kann über einen solchen Buffer-Overflow beliebiger Programmcode, auch Shell-Code genannt, eingeschleust und oft auch zur Ausführung gebracht werden.

Da der Angreifer bei einem Netzwerkdienst von remote aus arbeiten kann spricht man dann von einer Remote Code Execution Sicherheitslücke.

Sicherheitslücken dieser Kategorie gehören mit zu den schwersten IT-Schwachstellen und werden regelmäßig mit dem höchsten CVE-Score von 10.0 bewertet.

Buffer-Overflow-Exploits

Mit einem Buffer-Overflow-Exploit kann eine vorhandene Buffer-Overflow-Schwachstelle ausgenutzt. Das Ziel des Exploits ist der Zugriff auf das darunter liegende Betriebssystem von außen.

Dabei geht der Angreifer weit über das oben gezeigte einfache Beispiel hinaus und es wird direkt der Ausführungspfad so verändert, dass ein mit dem Buffer-Overflow mitgelieferte Shell-Code auch direkt zur Ausführung kommt.

Dieser Shell-Code enthält dabei beliebige durch den Angreifer vorgegebene Befehle. Häufig anzutreffen ist dabei das Erstellen einer Remote-Shell auf dem angegriffenen Rechner.

Folgen von Pufferüberläufen

Zu den üblichen Folgen eines Pufferüberlauf-Angriffs gehören Systemabstürze und die Gefahr der vollständigen Übernahme des IT-Systems durch einen Angreifer.

• Systemabstürze: Ein Buffer-Overflow-Angriff führt in der Regel zum Absturz der betroffenen Anwendung. Er kann auch dazu führen, dass das IT-System oder ein darauf laufender Webserver nicht mehr verfügbar ist oder Programme in eine Endlosschleife geraten.
• Angreifer übernimmt IT-System: Bei einem Buffer-Overflow-Angriff bringt der Angreifer häufig eigenen Shell-Code mit. Der Shell-Code wird dann auf dem verwundbaren Rechner durch den Buffer-Overflow ausgeführt. Damit hat der Angreifer die gleichen Rechte wie das laufende Programm mit der Buffer-Overflow-Schwachstelle. Sollte die Schwachstelle auf Ebene des Betriebssystems sein, wird der Shell-Code auch mit administrativen Rechten ausgeführt.
• Ausweitung der Rechte: Wenn ein Angreifer ein IT-System übernommen hat, besteht die Gefahr, dass weitere auf dem IT-System oder in der Netzwerkumgebung vorhandenen Sicherheitslücken ausgenutzt werden können.

Arten von Buffer-Overflow-Angriffen

Es gibt verschiedene Arten von Buffer-Overflow-Schwachstellen. Die drei häufigsten sind dabei:

1. Stack-basiertes Buffer-Overflow-Angriffe: Dies ist die häufigste Form von Buffer-Overflow-Sicherheitslücken. Der Stack-basierte Ansatz besteht darin, dass ein Angreifer Daten mit bösartigem Code an eine Anwendung sendet, die die Daten in einem Stapelpuffer speichert. Dadurch werden die Daten auf dem Stack, einschließlich des Rückgabezeigers, überschrieben, wodurch der Angreifer die Kontrolle über die Übertragungen erlangt.
2. Heap-basierte Buffer-Overflow-Angriffe: Ein Heap-basierter Angriff ist schwieriger auszuführen als der Stack-basierte Ansatz. Bei diesem Angriff wird der Speicherbereich eines Programms über den Speicher hinaus überflutet, den es für aktuelle Laufzeitoperationen verwendet.
3. Format-String-Angriffe Ein Format-String-Exploit findet statt, wenn eine Anwendung Eingabedaten als Befehl verarbeitet oder Eingabedaten nicht effektiv validiert. Dies ermöglicht es dem Angreifer, Code auszuführen, Daten im Stack zu lesen oder Segmentierungsfehler in der Anwendung zu verursachen. Dies könnte neue Aktionen auslösen, die die Sicherheit und Stabilität des Systems gefährden.

Welche Programmiersprachen sind am anfälligsten?

Nahezu alle nativen Anwendungen, Webserver und Webanwendungsumgebungen sind anfällig für Pufferüberläufe. Umgebungen, die in interpretierten oder Managed Code Sprachen wie C#, Java, Go, Rust und Python geschrieben sind, sind gegen diese Art von Angriffen immun. Durch die Nutzung von nativen Methoden und System-Calls kann aber auch hier die Ausnutzbarkeit nicht vollkommen ausgeschlossen werden.

Buffer-Overflow-Angriffe werden in der Regel durch Programmierfehler bei der Anwendungsentwicklung verursacht. Diese Probleme sind besonders in der Programmiersprache C/C++ problematisch, da sie von Haus aus keinen eingebauten Schutz vor Pufferüberläufen bietet.

Wie kann man als Programmierer Buffer-Overflows verhindern?

Buffer-Overflows sind ausnutzbar, weil Fehler im Design oder der Implementierung einer Software vorliegen. Für Software-Entwickler sollte immer der Grundsatz input is evil gelten. In der Umsetzung als Programmierer muss daraus folgen, dass jeder Input von außen – sei es über ein Webformular, ein Netzwerkdienst, eine Benutzereingabe über die Tastatur oder auch einfach nur durch das Einlesen einer Bilddatei sehr gewissenhaft verarbeitet werden muss.

Dazu gehört der korrekte Umgang mit unerwartet langen Zeichenketten, die Prüfung auf zulässige Eingabemuster, die Ausfilterung von verbotenen Zeichen (Blacklisting) oder die ausschließliche Annahme von erlaubten Zeichen (Whitelisting).

Die in den Beispielen gezeigten Pufferüberläufe resultierten aus einer unsauberen Verarbeitung einer unerwartet langen Zeichenkette. Eine einfache Prüfung auf die maximal zulässige Länge der Zeichenkette von 15 Zeichen hätte bereits ausgereicht.

Schutzmechanismen gegen Buffer-Overflow-Attacks

Aktueller Betriebssysteme und Compiler stellen Schutzmechanismen zur Verfügung die das erfolgreiche Ausnutzen von Buffer-Overflow Schwachstellen erheblich erschweren.

• Address Space Layout Randomization (ASLR): Buffer-Overflow-Exploits müssen in der Regel wissen, wo sich der ausführbare Code befindet. ASLR sorgt dafür, dass Systembibliotheken bei jedem Systemstart an eine andere Adresse geladen werden. Das erschwert die Nutzung aller System-Calls deutlich. Seit Windows Vista ist dieser Schutzmechanismus standardmäßig aktiv.
• Stack Canaries oder Stack Cookies: Ein Stack Cookie oder Stack Canary erschwert die Ausnutzung von Stack-basierten Buffer-Overflows erheblich, indem eine Zufallszahl auf dem Stack zwischen der Rücksprungadresse und den lokalen Variablen abgelegt wird. Bevor der Rücksprung in die aufrufende Funktion erfolgt, wird dieser Wert überprüft. Bei einer Veränderung, beispielsweise durch einen Buffer-Overflow, wird die Ausführung des Programmes direkt gestoppt. Das führt dann zwar zum Absturz der Software, aber nicht zur Systemübernahme. Dieser Schutzmechanismus muss im Compiler aktiviert werden.
• Data Exectuion Prevention (DEP): Diese Methode verhindert, dass Angreifer Code in nicht ausführbaren Bereichen ausführen können, indem Speicherbereiche als ausführbar oder nicht ausführbar gekennzeichnet werden. Dabei werden insbesondere Stack- und Heap-Bereiche als nicht ausführbar (NX) markiert. Seit Windows XP ist dieser Schutzmechanismus standardmäßig aktiviert.
• Überschreibschutz für strukturierte Ausnahmebehandlung (SafeSEH & SEHOP): Angreifer können versuchen, die strukturierte Ausnahmebehandlung (Structured Exception Handling, SEH) zu überschreiben. Das sind Funktionsadressen, an die in einem erkannten Fehlerfall gesprungen wird. Durch die zusätzliche Ablage der korrekten Adressen und einer regelmäßigen Prüfung wird verhindert, dass ein Angreifer diese überschreibt. Dieser Schutzmechanismus SEHOP greift auf Betriebssystemebene und benötigt keine Neu-Compilierung der Software, SafeSEH hingegen schon.

Wie wirkungsvoll sind die Schutzmechanismen der Compiler und Betriebssysteme?

Die automatisierten Schutzmechanismen gegen Buffer-Overflows können manchmal auch umgangen. Der Programmierer der Software ist und bleibt in der Verantwortung dafür zu sorgen, dass Buffer-Overflows gar nicht erst auftreten können.

• ASLR bietet nur Schutz für die Bibliotheken, die diese Funktionalität auch aktiviert haben. Bei einigen DLLs ist dieser Mechanismus abgeschaltet.
• Manchmal können Stack Cookies und Stack Canaries auch umgangen werden, wenn der Angreifer eine Ausnahmebehandlung vor Prüfung des Stack Canaries triggern kann. Bei gleichzeitiger Überschreibung der SEH kann dies dann wieder zu einem erfolgreichen Exploit führen.
• Data Execution Prevention (DEP) kann umgangen werden durch ein Konzept das ROP (Return Oriented Programming) genannt wird.
• Das Umgehen des Überschreibschutzes für die Ausnahmebehandlung ist recht schwierig, aber unter bestimmten Bedingungen möglich.