0. Technische Aspekte von Mac OS X und verwandte Themen Inhaltsverzeichnis

0.15 ASLR Cargo Cult Security

Warum ASLR nur für das Marketing gut ist, aber für die Sicherheit eher wertlos.

Dieser Artikel ist ein Fortsetzung des ASLR-Themas in Security orthodox. Dort hatte ich bereits über die Wirkungs- und Nutzlosigkeit von ASLR geschrieben. Oder anders ausgedrückt: Über die Nützlichkeit von ASLR als Marketing-Maßnahme. Hier ergänze ich nun weitere interessante Fakten.

Angriffs-Szenario

Bei sicherheitsrelevanten Bugs handelt es sich oft um Speicher-Überläufe. Das passiert, wenn man mehr in eine Speicherstelle schreiben kann als vorgesehen ist, indem das Programm mit unerwarteten Daten gefüttert wird. Dadurch überschreibt man nachfolgende Speicherbereiche, die oft sensible Daten enthalten, etwa die Adresse des nächsten auszuführenden Befehls. Der Programmablauf wird auf diese Weise verändert und springt zu Befehlen, die der Angreifer nützlich findet.

Früher hatten Angreifer einfach direkt die Befehle, die sie ausführen wollen, bei so einem Überlauf in den Speicher geschrieben und dann aufgerufen. Aber seitdem Daten durch DEP/NX erstmal nicht mehr ausführbar sind, und Code-Signing zum Beispiel in iOS dafür sorgt, daß nur noch passend signierter Code ausführbar ist, sind die Angreifer dazu übergegangen, vorhandenen ausführbaren Code zu recyclen. Programme sind voller Befehle, die man, in anderer Reihenfolge ausgeführt, auch für beliebige Angriffszwecke benutzen kann.

Es gibt Möglichkeiten solche nützlichen Programmstellen relativ leicht und automatisiert zu finden. Ferner kann nicht nur das Auffinden von APIs und Gadgets automatisiert erfolgen, sondern sogar auch der Angriffscode dynamisch erzeugt werden. Und wenn man schon einen Exploit hat, der zwar funktioniert, aber noch nicht für das Umgehen von ROP und ASLR vorbereitet ist, dann kann man daraus automatisiert einen Exploit erzeugen lassen, der auch ASLR und DEP umgeht.

In allen Fällen benutzt man eine der gefundenen nützlichen Programmstellen jeweils und springt dann immer wieder zurück, benutzt ein andere Stelle und springt wieder zurück und so weiter. Daher der Name ROP, Return-Oriented-Programming. Die einzelnen Puzzle-Teile, die man verwendet, nennt man dann ROP-Gadgets. Die meisten Programme sind so groß (meist reichen 20KB), daß sie alle nötigen typischen ROP-Gadgets bieten. Man kann sogar vollkommen unverdächtigen und nützlichen Quellcode in Open Source Projekte einbringen, der sich als Nebeneffekt im fertigen Programm dann als Angriffsbaustein, als ROP-Gadget herausstellt. Echt perfide, aber aus Techniker-Sicht eine elegante Meisterleistung, die ein Programm nach einem erfolgreichen Angriff wie ein verstecktes Waffenarsenal aussehen läßt.

ASLR

ASLR wurde neben anderen Techniken ursprünglich vom PaX-Team entwickelt, das Linux (den Kernel) besser vor Angriffen schützen wollte. Die Idee ist, daß man ein bewegliches Ziel schlechter treffen kann als ein stillstehendes. Wenn man die Befehle, die ein Angreifer aufrufen möchte, verstecken könnte, dann hätte er Schwierigkeiten, sie zu benutzen. Verstecken im eigentlichen Sinn geht natürlich nicht, aber man kann die Befehle ja eventuell an unbekannte Adressen im Speicher verschieben.

Die Wirksamkeit von ASLR hängt dann von diesen Praxis-Faktoren ab:

• Wieviele alternative Adressen gibt es, an denen man Programme, Libraries, Frameworks et cetera ablegen kann? Gibt es nur wenige andere Speicherorte, dann werden die Befehle zu schnell gefunden allein durch Ausprobieren.
• Die Zuordnung von Adressen sollte möglichst zufällig und schwer vorhersehbar sein.
• Es gibt immer Bugs, die dafür sorgen, daß die Adressen verraten werden.
• Viele Programme, speziell bei Windows, benutzen ASLR überhaupt gar nicht aus Kompatibilitätsgründen und verraten daher die Adressen.
• Es gibt wieder speziell bei Windows inoffizielle und offizielle APIs, die die Adressen preisgeben.
• Wie oft kann die Adresse gewechselt werden? Mit neuen Software-Versionen, nach Rechnerstart, nach Programmstart?

Dem PaX-Team waren diese Probleme anscheinend von Anfang an klar. Sie wußten, daß ASLR ziemlich leicht umgangen werden kann. Andererseits mußten sie auch etwas tun, um die Aushebelung von DEP/NX zu verhindern.

Besser als nichts

Sie wußten: ASLR ist nicht gut. Aber ASLR ist vergleichsweise billig zu implementieren. Und da somit das Preis/Leistungs-Verhältnis attraktiv war, haben sie ASLR umgesetzt. Allerdings war ASLR nie als endgültige Lösung geplant, weil sie es nicht für gut genug hielten. ASLR war von Anfang an nur als temporäre Lösung geplant.

Cargo Cult Security

Diese Hintergründe kannten viele nicht oder ignorierten sie. Da gab es plötzlich diese Idee von ASLR, die die Sicherheit verbessern können sollte. Darum haben sich andere Firmen wie Microsoft und Apple gedacht: Toll, das machen wir auch. Wie es implementiert wird, sehen wir ja, das machen wir einfach mal prinzipiell so nach, dann kommt die Sicherheit geflogen und landet bei uns. Daß ASLR von Anfang an nur als zeitlich begrenzte Krücke gedacht war, bis man eine vernünftige Lösung gefunden hat, die nicht so anfällig ist, daran dachte keiner mehr. Und es wollte auch keiner. ASLR war das neue Security-Buzzword und die Marketing-Abteilung wollte das auf die Packung schreiben. So kam es, daß jetzt die ganze Welt eine Notlösung benutzt und sich einen Wolf freut, was wir doch alles für tolle Sicherheits-Wizzards sind.

Und natürlich waren nun alle, die das nicht sofort ebenfalls in ihre Produkte einbauten, voll die Loser. Solche Hersteller wurden von den Technik-Zeitschriften, News-Seiten und Blogs gnadenlos mit Schimpf und Schande überzogen. In meinem Artikel Security orthodox habe ich diese verdrehte Ansicht von Sicherheit angeprangert. Alle Welt achtete nur noch auf technisch ziemlich wirkungslose Buzzwords wie ASLR und vergaß die Aspekte, die harte Sicherheit ausmachen.

Der Gipfel der Perversion war dann der Verkauf von Windows Vista als sicheres Betriebssystem, weil es unter anderem ASLR anbot. Anbot ja, aber nicht benutzte, denn praktisch alle Programme liefen ohne ASLR, weil sie nicht damit kompatibel waren. Vistas zweites Standbein war die UAC, ein Sicherheits-Plazebo, ein Holzbein, bei dem die Säge gleich dabei liegt.

Apple führte ASLR etwas später ein, und hat inzwischen eine lückenlose Implementierung, die vorbildlich ist und mit viel weniger Realitäts-Problemen (Inkompatibilität und vergeigte APIs, dazu unten mehr) zu kämpfen hat als Microsoft. Dennoch ist es ein Irrtum, ASLR als wirkungsvollen Schutz zu betrachten. Auch bei Apple.

Als Verlierer geboren

Wie effektiv ist ASLR in der Praxis? Wo liegen die Grenzen?

Entropie

Je nachdem, wie gut man Code "verstecken", genauer: wie zufällig man ihn anordnen kann, desto besser. Wenn es nur wenige Variations-Möglichkeiten gibt, dann kann sie der Angreifer schnell durchprobieren. Gibt es hingegen sehr viel Entropie, dann wird das Raten und Durchprobieren zu aufwendig und man muß einen der anderen Wege gehen, um ASLR wirkungslos zu machen. Ausprobieren ist natürlich der einfachste Weg für den Angreifer.

Die mögliche Entropie wird durch Hardware und Software eingeschränkt:

Entropie Hardware-Einschränkungen

Je größer der Adreßraum ist, den die Hardware möglich macht und die das Betriebssystem auch benutzt, desto besser stehen die Chancen auf möglichst zufälliges Verstecken. Jedes Mal, wenn ich Berichte über 64-Bit-Hardware lese, die erzählen, man brauche die ja noch gar nicht und es würde auch nicht viel bringen, dann überkommt micht ein kaltes Erschauern: 32-Bit-Programme sind völlig witzlos hinsichtlich ASLR. Man kann jeden beliebigen Standard-Buffer-Overflow-Exploit ASLR-tauglich machen. Der anschließende Angriff damit wird durch ASLR bei 32-Bit-Code um circa 200 Sekunden verlangsamt, wenn man Hardware von 2004 (also von vor 10 Jahren) einsetzt.

Entropie Software-Einschränkungen

Während des Boot-Prozesses steht dem iPhone zum Beispiel noch nicht der richtige Pseudo-Zufallszahlen-Generator zur Verfügung, sondern nur der "early pseudo random number generator", der eine nicht so hohe Entropie bieten kann wie der, der nach dem Ende des Bootprozesses verfügbar ist. Darum ist ASLR im iOS-Kernel leichter auszuhebeln per Brute Force. Das liegt einfach daran, daß eingebetteten Systemen wie iOS nicht so viele geeignete Quellen für Entropie zur Verfügung stehen während des Startens wie Desktop-Systemen. Nach dem Boot-Prozeß kommen Apps wie Safari oder Mail allerdings in den Genuß des besseren Zufallsgenerators. Der Kernel nicht.

Auch auf OS X ist die Entropie des sogenannten Kernel-Schlittens so gering, daß ein Exploit problemlos einfach alle infrage kommenden Adressen ausprobiert. Hier dient muymacho als Praxis-Beispiel. Der "Schlitten" ist der Wert, um den die Adressen verschoben werden durch ASLR.

Auf 64-Bit Windows 8.x haben Programme, die eine Basis-Adresse unterhalb von 4 GB im virtuellen Speicher bekommen, nur eine Entropie von 8 Bit. Der Grund sind wie so oft bei Windows Probleme mit der Abwärts-Kompatibilität: 32-Bit-Windows-Versionen nutzen 8 Bit Entropie für alles, also EXE- und DLL-Images. Damit nutzen also viele Programme selbst auf 64-Bit Windows kein ASLR mit nennenswerter Entropie. 8 Bit Entropie stellen kein Hindernis dar. ASLR mit 8 Bit Entropie kann man sich gleich ganz sparen, weil es völlig nutzlos ist. Das bedeutet auch, daß ASLR auf Windows mit 32 Bit und auf allen Windows-Version vor 8 vollkommen sinnlos ist, eine reine Veralberung des Users, der damit in falscher Sicherheit gewogen wird.

Beweglichkeit

Ein bewegliches Ziel ist eine tolle Idee, aber wenn es sich nur einmal bewegt und dann stehenbleibt, wird es trotzdem schnell gefunden. Das gilt für alle System-Kernel. Sie haben nicht nur aufgrund des Boot-Prozesses eine eingeschränkte Entropie, sondern sind auch dazu verdammt, die ganze Laufzeit über ihre Basis-Adresse nicht mehr zu ändern. Kernel-ASLR ist darum prinzipiell broken by Design, ein schwachsinniger Marketing-Stunt. So hat zum Beispiel iOS KASLR nur 8 Bit Entropie.

Ähnliches gilt auch für Libraries: Sie bekommen auch nur bei einem Neustart eine geänderte Basis-Adresse. Der Cache für dynamische Libraries wird sogar im schlimmsten Fall nur nach Software-Updates verändert, dafür ist er ja da. Dadurch sind die zufälligen Adressen der Libraries aber leider über einen längeren Zeitraum gleichbleibend pro Rechner und nur unterschiedlich zwischen verschiedenen Rechnern.

Information Leaks

Beim Versteckspiel, die coolen Kids nennen es ASLR, kommt es natürlich darauf an, daß niemand das Versteck, die Basis-Adressen der verschiedenen Programme und Libraries et cetera verrät. Und das ist wie im richtigen Leben bei ASLR ebenfalls eine völlig unrealistische Annahme. Es gibt verschiedene Varianten von Informations-Lecks.

Bugs

Es gibt immer wieder Bugs im Kernel und in Userland-Programmen, die interessante Adressen verraten. Ein einziges Informationsleck genügt, um ASLR wertlos zu machen.

Im Kernel jedes Betriebssystems sind unglaublich viele Information Leak Bugs allein aus dem Grund, weil es lange Zeit gar keine Notwendigkeit gab, solche Informations-Quellen zu schließen geschweige denn diese systematisch zu eliminieren oder wenigstens ihre Auswirkung zu verhindern. Die alle zu finden und zu beseitigen im Nachhinein wird auf allen Systemen noch sehr lange dauern.

Nicht-Mitspieler

Es gibt so gut wie immer Programme, Libraries et cetera, die kein ASLR verwenden und dadurch andere Bereiche des Systems oder die anderen Programme kompromittieren, obwohl diese selbst ASLR verwenden. Als Beispiel sei hier Dropbox für Windows genannt, das ASLR für andere Programme ruiniert. Dropbox fügt Funktionalität zu laufenden anderen Programmen hinzu, indem es eine eigene Library injiziert, die allerdings keine ASLR verwendet. Dadurch verliert jedes dieser Programme, zum Beispiel Firefox, seine ASLR-Pseudo-Sicherheit.

Inoffzielle und offizielle APIs

Es ist eine traurige Tatsache, daß alle aktuellen Betriebssysteme by design Features anbieten, die alle Adress Informationen zur Verfügung stellen, die ein Exploit benötigt.

Laut einem Vortrag von Alex Ionescu gibt es sehr viele inoffzielle und sogar offizielle APIs in Windows, die einem Kernel-Adressen auf einem Silbertablett servieren. Man ist gar nicht auf Bugs oder Programme ohne ASLR angewiesen, sondern ruft einfach nur die richtige Funktion auf und fragt nett: Windows nennt einem die Kernel-Adressen dann freiwillig. Und das ist der absolute Ober-Hammer. Windows versucht einerseits, ASLR möglichst flächendeckend einzusetzen, andererseits schießt es sich aber by Design (!) selbst in den Fuß, indem es die zufälligen Adressen auf Nachfrage verrät.

Alex führt explizit aus, daß Apple hier deutlich strenger ist und auf solchen Unfug achtet. Im OS X Kernel käme es nicht vor, daß irgendwelche offiziellen APIs die Adressen verraten. Aber es kommt noch besser. Windows hat die Kernel-Adressen an jedes Programm verraten, auch an unprivilegierte Prozesse. Mit Windows 8.1 gab es Verbesserungen dazu, so daß wenigstens ein mittlerer "Integrity Level", um viele der betroffenen Funktionen aufzurufen, notwendig wurde. Da aber die UAC und Integrity Level ebenfalls broken by Design sind, nützt das auch nicht wirklich etwas.

Dies ist ein Paradebeispiel dafür, wie Windows aufgrund irgendwelcher Buzzwords wie ASLR als "sicher" verkauft wird, es tatsächlich jedoch nicht die Bohne ist.

Fazit

Wenn Ihr das nächste Mal das Wort ASLR im Zusammenhang mit Sicherheit hört, dann denkt daran, daß es nur ein Verkaufs-Argument ist, das sein Sicherheits-Versprechen nicht einmal ansatzweise halten kann. Und zwar auf allen Plattformen zu allen Zeiten. Besonders groß ist allerdings der Unterschied zwischen Marketing und technischer Wahrheit auf Windows. Da ASLR ein totes Pferd ist, ist es DEP/NX auch, denn die Nichtausführbarkeit von Daten nützt nichts, wenn man ohne ASLR oder mit ausgehebeltem ASLR vorhandenen Code anspringen kann, weil man dessen Adresse kennt.

Ich hatte in Security orthodox schon darauf hingewiesen, daß ASLR und DEP/NX, die von vielen "Sicherheitsforschern" und News-Seiten über den grünen Klee gelobt werden, nutzloser Mist sind, wenn man von der Irreführung des technisch weniger versierten Durchschnitts-Users absieht.

---