Exploits mit Security-Funktionen wie ASLR, DEP und Bounds Checking stoppen

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

SEPPmail - Deutschland GmbH

Stack-Overflows mit Compiler-Erweiterungen unterbinden

Durch die berühmt-berüchtigte Anleitung „Smashing The Stack For Fun And Profit“ von Aleph One, wurde 1996 erstmals einer breiten Öffentlichkeit das Problem von Buffer Overflows bewusst gemacht. Nur zwei Jahre später stellten Forscher auf dem USENIX Security Symposium eine Lösung vor: StackGuard. Wichtigster Bestandteil dieser Erweiterung des GNU C Compilers war die Einführung eines so genannten „Canary“.

Dieses wird zu Anfang einer jeden Funktion im Speicher platziert und vor dem abschließenden Rücksprung erneut überprüft. Ist der Wert des „Canary“ anders als anfangs gesetzt, deutet alles auf einen Pufferüberlauf hin und StackGuard beendet den Prozess.

Wegen diverser Schwächen wurde das Projekt nie offiziell Teil von GCC. Stattdessen wurde der Stack-Smashing Protector (SSP) von IBM mit Version 4.1 der GNU Compiler Collection auf breiter Basis etabliert. Dieser beseitigte viele Schwächen der ursprünglichen StackGuard-Implementation der Canary-Methode und führte weitere Schutzmechanismen ein.

Was bei Linux „Canary“ heißt, nennt sich bei Microsoft „Security Cookie“ und wird über die Compiler-Option /GS aktiviert. Technisch betrachtet sind sich die beiden Konzepte sehr ähnlich. Ihr Hauptziel ist der Schutz der auf dem Stack abgelegten Verwaltungsinformationen wie der Rücksprungadresse. Vor anderen Angriffstechniken wie Heap- oder BSS-Overflows schützt jedoch weder das „Canary“ noch das „Security Cookie“.

Nur zusammen mit ASLR bietet DEP ausreichend Schutz

Die bislang vorgestellten Maßnahmen versuchten stets zu erkennen, ob ein Puffer übergelaufen war, um den Prozess anschließend zu stoppen. Das von Microsoft Data Execution Prevention (DEP) genannte Konzept verfolgt einen komplett anderen Ansatz. Anstatt den Buffer Overflow zu verhindern, sorgt DEP dafür, dass vom Angreifer eingeschleuster Shellcode nicht ausgeführt werden kann.

Um ein Speichersegment als nicht ausführbar zu markieren, verfügen moderne CPUs über ein spezielles Bit, welches bei AMD NX- (No eXecute) und Intel XD-Bit (eXecute Disable) heißt. Versucht ein Angreifer dennoch eigenen Code im Speicher zu starten, führt dies zu einem Hardware-Interrupt, der den Prozess stoppt.

Zunächst schien die Gefahr von Buffer Overflows tatsächlich gebannt. Es dauerte jedoch nicht allzu lange bis Exploits auftauchten, die auch ohne das Einschleusen eigenen Codes reibungslos funktionierten. Dazu legten sie präparierte Werte auf dem Stack ab und verbogen den Programmfluss dergestalt, dass Standard-C-Funktionen wie system() gestartet werden. Diese fanden dann die vom Angreifer hinterlegten Parameter vor und verwendeten sie.

Gegen diese als Return-into-libc bezeichnete Technik ist der von DEP gewählte Ansatz leider machtlos. Nicht jedoch ASLR! Wie es der Name schon vermuten lässt, sorgt Address Space Layout Randomization dafür, dass der Adressbereich des Prozesses (möglichst) zufällig gewählt wird. So wird es für einen Angreifer schier unmöglich den genauen Ort einer Funktion wie system() zu kennen und der Exploit verläuft im Sande.

Inhalt

• Seite 1: Unsichere Bibliotheksfunktionen mit Libsafe abfangen
• Seite 2: Stack-Overflows mit Compiler-Erweiterungen unterbinden
• Seite 3: Alternative Sprachen mit automatischem Bounds Checking

(ID:2050475)