ASLR: Speicher-Randomisierung unter Linux mangelhaft

Die Randomisierung des Speicherlayouts (ASLR) gilt als wichtige Maßnahme, um die Ausnutzung von Sicherheitslücken zu erschweren. Unter Linux hat das Konzept Mängel, aber viel gravierender ist, dass vielfach ASLR überhaupt nicht eingesetzt wird.

Artikel veröffentlicht am 8. Dezember 2014, 16:00 Uhr, Hanno Böck

PaX liefert eine deutlich bessere Speicherrandomisierung als der Standard-Linux-Kernel. (Bild: PaX)

Zu den häufigsten Sicherheitslücken gehören Fehler in der Speicherverwaltung von C-Programmen, beispielsweise klassische Buffer Overflows. Moderne Betriebssysteme haben inzwischen eine Reihe von Schutzmaßnahmen implementiert, um die Ausnutzung von solchen Fehlern zu erschweren. Eine Möglichkeit ist die sogenannte Address Space Layout Randomisation (ASLR).

Eine Strategie zur Ausnutzung von Sicherheitslücken ist es häufig, das System des Opfers dazu zu bringen, an eine bestimmte Stelle im Speicher zu springen und dort Code auszuführen. Damit derartige Angriffe jedoch funktionieren, muss der Angreifer wissen, an welchen Speicheradressen sich was befindet. Hier setzt ASLR an: Durch die zufällige Verteilung von Code, Heap und Stack im Speicher werden solche Angriffe enorm erschwert. ASLR ist nicht perfekt. Durch die Nutzung von weiteren Lücken kann ein Angreifer Speicheradressen erfahren, das sogenannte Heap Spraying setzt darauf, bösartigen Code möglichst oft im Speicher zu wiederholen, so dass bei einem zufälligen Sprung die Chance besteht, den entsprechenden Code zu erreichen. Doch auch wenn ASLR nicht alle Angriffe verhindert, gilt es als wichtiger Baustein moderner Sicherheitskonzepte.

Linux war Pionier in Sachen ASLR

Linux war eigentlich einst Pionier in Sachen Speicherrandomisierung. Das PaX-Projekt hatte bereits 2002 mittels eines Kernel-Patches die Möglichkeit von ASLR eingeführt. Ein Jahr später führte OpenBSD als erstes Betriebssystem ASLR als Standardfunktion ein. PaX existiert noch heute und ist Teil des Grsecurity-Projekts, das einen Kernel-Patch mit zahlreichen zusätzlichen Sicherheitsfunktionen für den Linux-Kernel bereitstellt. Doch PaX wurde nie Teil des offiziellen Linux-Kernels. Mit der Version 2.6.12 führte Linux eine eigene Implementierung von ASLR ein. Doch das Problem dabei: In vielen Fällen greift diese überhaupt nicht. Während unter Windows, Mac OS X, Android und iOS ASLR inzwischen Standard ist, wird es unter Linux nach wie vor nur mangelhaft genutzt.

Der Hintergrund ist, dass nicht jedes Programm automatisch an beliebige Speicherbereiche geladen werden kann. Klassischerweise können Sprungbefehle in Software auf feste Adressen verweisen. Damit der Code an beliebige Speicherbereiche geladen werden kann, muss dies bereits bei der Kompilierung berücksichtigt werden. Der gcc-Compiler bietet hierfür die Option -fpic (pic steht für "Position Independent Code"), für den Linker muss die Option -pie (für "Position Independent Executable") angegeben werden. Und genau hier hapert es: Alle großen Distributionen nutzen standardmäßig noch Programme, die nicht mit den entsprechenden Optionen für positionsunabhängigen Code kompiliert wurden.

Geringe Auswirkungen auf die Leistungen

Die Nutzung von positionsunabhängigem Code hat Auswirkungen auf die Performance. Insbesondere auf alten PC-Systemen mit 32 Bit ist das ein Problem, denn hier ist die Zahl der Prozessorregister knapp und für den positionsunabhängigen Code wird ein zusätzliches Register benötigt. Auf 64-Bit-Systemen sind die Performanceeinbußen hingegen sehr gering. Bei einem Test von uns mit der Codierung eines Videos mit dem Programm ffmpeg betrug der Unterschied etwa 1,5 Prozent. Es gibt Patches für den gcc-Compiler und Binutils, welche die Leistungseinbußen noch weiter reduzieren und die in den kommenden Versionen der entsprechenden Tools enthalten sein werden.

Auch ohne positionsunabhängigen Code ist die Adressrandomisierung nicht völlig nutzlos. Der Stack- und der Heap-Speicher landen trotzdem an zufälligen Adressen und Bibliotheken werden generell mit positionsunabhängigem Code kompiliert. Aber für einen wirklichen Schutz reicht das nicht. Insbesondere um vor sogenannten Return-Oriented-Programming-Angriffen zu schützen, ist eine Randomisierung des eigentlichen Programmcodes wichtig.