Software-Sicherheit – Teil 3 Exploits mit Security-Funktionen wie ASLR, DEP und Bounds Checking stoppen

Mit dem Security Development Lifecycle (SDL) setzte Microsoft ein klares Zeichen: Sicherheit ist ein Prozess und kein Produkt. Für Windows Vista wurden erstmals Richtlinien angewendet und Techniken wie ASLR und DEP eingesetzt. In diesem Beitrag betrachtet Security-Insider.de verschiedene Methoden zur Abwehr von Exploits und zeigt, wo deren Grenzen liegen.

Anbieter zum Thema

Arvato Systems

TXOne Networks

Keeper Security EMEA Ltd.

Bereits im Mai 2000 formulierte Bruce Schneier in seinem Newsletter „Crypto-Gram“ einen Satz, der erst Jahre später zum Leitsatz für die Entwicklung sicherer Systeme werden sollte: „Security is a process, not a product.“ Dahinter steckt vor allem die Überzeugung, dass es keine hundertprozentig sicheren Systeme gibt und vermutlich auch nie geben wird.

Prozesse wie SDL können die Menge an Software-Fehlern zwar deutlich reduzieren, jedoch nicht komplett ausschließen. Um die Hürde anzuheben, einen funktionsfähigen Angriffscode zu schreiben, setzen moderne Betriebssysteme zusätzlich auf Technologien wie ASLR (Address Space Layout Randomization) und DEP (Data Execution Prevention).

Auch im Umgang mit Bug Huntern hat sich jüngst einiges getan. Unternehmen wie Google setzen verstärkt auf Zusammenarbeit und loben Prämien aus. Wer kritische Fehler in Webservices des Konzerns findet und meldet, erhält je nach Art des Problems bis zu 3133,70 US-Dollar. Die Mozilla Foundation folgte diesem Vorbild und erweiterte ihr eigenes Prämienprogramm ebenfalls auf Webdienste.

Ob durch faires Verhalten gegenüber Personen, die Fehler melden, bei der Wahl der Programmiersprache oder beim Einsatz diverser Schutzmechanismen gegen Exploits: Sicherheit ist immer ein Prozess, der aus vielen kleinen Teilen besteht. Einige davon werden in den folgenden Abschnitten weiter vertieft.

Unsichere Bibliotheksfunktionen mit Libsafe abfangen

Aufgrund ihrer Komplexität gilt die Programmiersprache C als zweischneidiges Schwert. Für systemnahe bzw. hochperformante Anwendungen auf mobilen Endgeräten ist sie häufig die erste Wahl. Leider sind viele Funktionen extrem fehleranfällig. Von der Benutzung manch einer wird sogar offen abgeraten:

„Never use gets().“ – Auszug aus der gets(3)-Manpage

Funktionen wie strcpy(), strcat(), scanf(), sprintf() und weitere haben alle eines gemein: Fehlendes Bounds Checking (Grenzwert-Kontrolle). Ankommende Daten lassen sich nicht direkt begrenzen und werden auch dann in den Zielpuffer kopiert, wenn dieser viel zu klein ist. Das Ergebnis ist ein klassischer Buffer Overflow.

Kritisch wird es jedoch dann, wenn die Daten vom Anwender stammen und dieser sie so manipuliert, dass der Programmfluss gezielt verbogen wird. Um derartige Fehler abzufangen, bedient sich Libsafe der Umgebungsvariable LD_PRELOAD. In dieser lassen sich dynamisch ladbare Bibliotheken angeben, deren Funktionen beim Start einer ELF-Datei Vorrang genießen sollen.

Mit Hilfe dieses Tricks „überschreibt“ Libsafe einzelne unsichere Standard-C-Funktionen mit Alternativen, welche den Prozess im Falle eines Pufferüberlaufs sofort stoppen. So lässt sich möglicher Schaden immerhin begrenzen; die Ursache des Problems bleibt jedoch weiterhin bestehen.

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)