Original-URL des Artikels: https://www.golem.de/news/aslr-speicherrandomisierung-unter-linux-mangelhaft-1412-111010.html    Veröffentlicht: 08.12.2014 16:00    Kurz-URL: https://glm.io/111010

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.

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.

Firefox hat ASLR nach Problemen wieder deaktiviert

Mozilla hatte vor kurzem versucht, Firefox für Linux mit den entsprechenden Optionen zu kompilieren. Dabei trat ein unerwartetes Problem auf: Der GNOME-Dateimanager Nautilus erkannte die entsprechend kompilierten ausführbaren Dateien nicht als solche und Firefox ließ sich über den Dateimanager nicht starten. Firefox schaltete daraufhin die entsprechende Funktion wieder ab.

Der Grund für die Nautilus-Probleme, die bei einem Test von Golem.de unter dem KDE-Dateimanager Dolphin in genau derselben Form auftraten: Der Dateimanager greift zur Erkennung von ausführbaren Dateien auf die Bibliothek libmagic zurück, die Teil des Tools file ist. Die libmagic-Bilbiothek wiederum kann positionsunabhängige Linux-Binaries nicht von Bibliotheken unterscheiden und liefert den MIME-Type für Bibliotheken zurück. Sowohl Binaries als auch Bibliotheken verwenden unter Linux das Elf-Dateiformat.

Chrome wird standardmäßig mit Adressrandomisierung ausgeliefert, ebenso der auf Firefox basierende Tor-Browser. Anders als Mozilla liefern diese beiden Browser ein Shellskript zum Starten mit, sie sind somit von dem Problem in den Dateimanagern nicht betroffen.

In Linux-Distributionen kein Standard

Bei den Linux-Distributionen ist die Situation in Sachen ASLR sehr gemischt. Fedora und Debian aktivieren das Feature nur für einzelne Tools, die als besonders sicherheitskritisch gelten. Gleiches gilt auch für andere auf Debian basierende Distributionen wie Ubuntu. Selbst Tails, ein auf Datenschutzeinstellungen und Sicherheit getrimmtes Linux-System, nutzt ASLR nicht standardmäßig.

Es gibt auch immer wieder generelle Probleme mit der ASLR-Implementierung von Linux. Mitglieder von Google's Projekt Zero entdeckten beim Versuch, eine Glibc-Sicherheitslücke auszunutzen, dass man zumindest unter 32-Bit-Systemen die Speicherrandomisierung von Suid-Binaries mit Hilfe des Befehls ulimit weitgehend deaktivieren kann.

offset2lib-Schwäche entdeckt

Zuletzt hatten die Sicherheitsforscher Hector Marco-Gisbert und Ismael Ripoll auf der Deepsec-Konferenz in Wien eine ausführliche Analyse des ASLR-Konzepts von Linux vorgestellt und ein weiteres Problem entdeckt, das sie offset2lib getauft haben: Linux legt zwar den Programmcode an einer zufälligen Stelle im Speicher ab, aber der Hauptprogrammcode und der Code von nachgeladenen Bibliotheken wird immer im selben Abstand abgelegt. Das bedeutet, dass ein Angreifer, der im Hauptprogramm aufgrund eines Fehlers möglicherweise Kenntnis von einer Speicheradresse erlangt, damit eine Sicherheitslücke in einer Bibliothek ausnutzen kann.

Android ist von der offset2lib-Schwäche ebenfalls betroffen. Anders als unter gängigen Linux-Distributionen kommt unter Android in aller Regel auch Adressrandomisierung zum Einsatz. Nicht betroffen sind Linux-Systeme, die Pax benutzen. Die Forscher haben einen Patch vorgelegt, der zur Zeit auf der Kernel-Mailingliste diskutiert wird.

Solange die meisten Linux-Distributionen aber keine Dateien mit positionsunabhängigem Code ausliefern, hilft das alles nicht viel. Die Distributionen sollten hier dringend handeln und die Speicherrandomisierung mittels ASLR auch unter Linux zum Standard machen.  (hab)


Verwandte Artikel:
Counter-Strike Go: Bei Abschuss Ransomware   
(22.07.2017, https://glm.io/129078 )
Librem 5: Purism-Smartphone bekommt Smartcard für Verschlüsselung   
(09.03.2018, https://glm.io/133248 )
E-Mail-Clients für Android: Kennwörter werden an App-Entwickler übermittelt   
(06.03.2018, https://glm.io/133172 )
Starcraft Remastered: Warum Blizzard einen Buffer Overflow emuliert   
(06.02.2018, https://glm.io/132612 )
Pax: Google will Patentstreit im Android-Ökosystem verhindern   
(04.04.2017, https://glm.io/127114 )

© 1997–2019 Golem.de, https://www.golem.de/