daily.out

2011-07-25 Der Löwenanteil an Sicherheit

Mit Mac OS X 10.7 Lion gab es neue Sicherheits-Features. Einige sind offensichtlich und werden von der Presse an die große Glocke gehängt, ohne daß sie es verdient hätten. Andere sind nicht so offensichtlich, aber wirkungsvoller.

Unwichtig und plakativ: Volles ASLR und DEP

Lion hat nun das, was Charlie Miller und Dino Dai Zovi "volles ASLR" nennen: Zusätzlich zu den Shared Libraries sind nun auch die Speicher-Positionen eines Programms selbst und die seines Data-Segments, Heaps und Stacks an zufälligen Positionen.

Ob ein Programm ASLR verwendet, kann man an dem PIE-Flag sehen:

KeyWest:~ macmark$ otool -arch all -hvr /Applications/Safari.app/Contents/MacOS/Safari /Applications/Safari.app/Contents/MacOS/Safari (architecture x86_64): Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 16 1688 NOUNDEFS DYLDLINK TWOLEVEL PIE /Applications/Safari.app/Contents/MacOS/Safari (architecture i386): Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC I386 ALL 0x00 EXECUTE 16 1332 NOUNDEFS DYLDLINK TWOLEVEL PIE MH_NO_HEAP_EXECUTION

Bislang war der Stack in 32 und 64 Bit nicht ausführbar. Ebenso der Heap in 64 Bit. Mit Lion ist auch der Heap mit 32 Bit nicht ausführbar und das Data-Segment. Da so gut wie alle Programme 64-bittig sind, bringt die Verbesserung für den 32-Bit-Heap nicht viel.

Die Änderungen klingen erstmal wichtig, aber tatsächlich sind ASLR und DEP relativ wirkungslos, da sie heutige Exploits nicht verhindern können und es inzwischen gang und gäbe ist, Exploits unter Berücksichtigung von ASLR und DEP zu schreiben. Der einzig reale Vorteil wäre, daß haufenweise alte Exploits aus der Zeit vor ASLR und DEP nicht mehr funktionieren würden. Davon gibt es jedoch nur unter Windows wirklich viele.

Jetzt rächt sich, daß die Windows-Fraktion ASLR und DEP sicherheitstechnisch überbewertet, denn Lion hängt Windows in diesem Punkt ab:

32-Bit-Versionen von Windows, die überwiegend eingesetzt werden, haben DEP für Anwendungsprogramme standardmäßig nicht aktiviert. Bei Lion hingegen kann der User DEP/NX überhaupt nicht abschalten und beim Bauen der Applikation ist es voreingestellt aktiviert.

Viele Programme unter Windows verwenden immer noch kein ASLR und die Implementierung von ASLR unter beispielsweise Vista stellte sich als ziemlich schlecht, weil vorhersagbar, heraus. Bei Lion ist ASLR beim Bauen der Applikation voreingestellt.

Man kann also davon ausgehen, daß in Kürze sämtliche Programme für Lion mit NX/DEP und ASLR laufen, während das bei Windows nicht der Fall ist. Windows hat "volles ASLR und DEP" in der Theorie, Lion hat es in der Praxis.

Wie gesagt: ASLR und NX sind allenfalls die Sahne auf dem Sicherheitskuchen, da sie keine harte Sicherheit bieten, sondern eher "Security by Obscurity".

Wichtig: Offizielles Sandboxing

Apple hatte mit 10.5 Leopard Sandboxing eingeführt, das das MAC-Framework von TrustedBSD verwendet.

Apple setzte Sandboxing zuerst für einige ausgewählte Systemdienste ein, die einerseits eine exponierte Angriffsfläche boten und andererseits recht klar begrenzte Ressourcen benötigten. Die verwendete API war privat und undokumentiert und nicht für Dritte freigegeben.

Im Zuge der folgenden Updates wurden immer mehr Systemdienste mit Sandboxen abgesichert. Und wie man an Googles Chrome und meiner Sandbox für Safari sehen konnte, ließ sich die undokumentierte API auch mit GUI-Anwendungen einsetzen, obwohl bei diesen nicht so leicht zu erkennen ist, welche Sandbox-Beschränkungen geeignet sind, da User-Apps keine so klaren und fixe Ressourcen-Bedürfnisse haben wie Systemdienste.

Apple hat drei wesentliche Punkte für das Sandboxing eingeführt, die den Erfolg des Konzeptes und des damit verbundenen Sicherheitsgewinns garantieren:

Offiziell und einfach

Mit OS X Lion hat Apple eine offizielle, dokumentierte und einfach handhabbare API für Sandboxen eingeführt, die auf dem bisherigen aufsetzt. Entwickler können die Sandbox-Funktionen durch einfaches Anhaken in ihrem Projekt verwenden und aus übersichtlichen Optionen wählen.

Eine Sandboxfunktion, die schwierig zu benutzen ist, würde niemand einsetzen. Lion bietet daher eine konkurrenzlos simpel einsetzbare Möglichkeit, Sandboxen zu verwenden. Dazu hat Apple zwei weitere Ergänzungen vorgenommen:

Dynamik für GUI-Apps

Da User-Apps keine feste Menge an Ressourcen nutzen, sondern beispielsweise auch vom Benutzer erstellte oder gewählte Dateien lesen oder schreiben müssen, hat ein starres Sandbox-Modell immer einen Nachteil: Entweder man läßt zuviel zu oder der Benutzer kann nicht alles tun, was er möchte. Beides ist für ein Desktop-System unschön und verhindert den praktischen Einsatz.

Um die seit 10.5 Leopard verfügbare Sandboxing-Technik für GUI-Apps passend zu machen, fügt Lion dynamisch Dateien und Verzeichnisse zur jeweiligen App-Sandbox hinzu. Ohne daß der Entwickler Änderungen an seiner App dafür vornehmen müßte, werden Öffnen- und Sichern-Dialoge nicht mehr vom App-Prozeß selbst präsentiert, sondern vom neuen Powerbox-Dämon. Die vom Benutzer in diesen Dialogen gewählten Dateien werden der Sandbox der App hinzugefügt. Zusätzlich werden System-Dienste wie Drag&Drop sowie die Liste der zuletzt benutzten Dateien für die sandboxed App transparent unterstützt.

Alle nicht vom Benutzer erstellten, aber von der sandboxed App verwendeten Daten, liegen in einem Container-Unterverzeichnis der User-Library. Durch die App-Signatur ist der zugehörige Container eindeutig bestimmt. Die Cocoa-APIs geben für sandboxed Apps das Container-Verzeichnis als das Home des User an. Versucht eine App auf andere Weise auf das User-Home oder Daten außerhalb der Sandbox zuzugreifen, wird dies von der Sandbox verhindert.

Du kannst Dir im Activity Monitor eine "Sandbox"-Spalte anzeigen lassen, in der Du siehst, welche Prozesse sandboxed sind.

Splitting

Man kann keine einzelnen Threads sandboxen, sondern nur ganz Prozesse. Jeder Prozeß, der einen weiteren Prozeß startet, vererbt seine Sandbox an diesen. Daher gibt es eine dritte Ergänzung, um Sandboxing erfolgreich zu machen, die darin besteht, das Aufsplitten einer Applikation in mehrere unterschiedlich gesandboxte Prozesse und deren Kommunikation untereinander zu erleichtern.

Dazu wird die Applikation in mehrere Binaries aufgeteilt innerhalb des Applikations-Bündels. Die neben dem Haupt-Binary genutzten Binaries sind XPC-Services, die keinen fork/exec Lifecycle haben, sondern automatisch von XPC gemanaged werden. XPC ist eine neue Schicht für Inter-Prozeß-Kommunikation in Lion. Auf unterer Ebene arbeitet dazu launchd, aber man muß diese Dienste nicht wie sonst definieren. Sobald die App ihre Dienste kontaktiert, werden sie gestartet von XPC, am Leben gehalten und bei Nichtbenutzung auch wieder beendet. Diese XPC-Dienste sind nur für die App verfügbar und für nichts sonst.

Lions Safari beispielsweise wurde schon in einen Hauptprozeß und einen XPC-Service zerlegt, der Safari Web Content heißt und gesandboxt ist. Das Rendering von Web-Inhalten erfolgt also nun abgeschottet vom Rest der Userdaten. Außerdem laufen nicht nur Flash und Quicktime bei Safari in einem eigenen Prozeß, sondern ab Lion alle Browser-Plugins inklusive Java, was man bislang separat einstellen mußte. Da die WebKit-Plugin-API damit inkompatibel ist, müssen alle Plugins die Netscape Plugin-API übernehmen.

Das wichtigste: Sandbox-Pflicht

Ab November 2011 sollten sämtliche Apps, die in den Mac App Store kommen, gesandboxt sein. Am 2. November hat Apple jedoch diese Deadline auf den 1. März 2012 verschoben. Jede Erlaubnis, die man seiner App spendieren möchte, muß begründet sein.

Es gibt keine andere Plattform, die so eine Sandbox-Pflicht durchsetzen könnte. Mit dem App Store kann Apple die Entwickler dazu zwingen. Da wie oben beschrieben, die Nutzung einer Sandbox für Mac-Apps ein Kinderspiel ist, besteht auch kein Grund, etwas anderes zu wollen.

Ab dem Jahresende wird sich somit die Angriffsfläche auf dem Mac dramatisch verringern.

Härter

Lion und seine aktualisierte Entwicklungsumgebung haben ein paar neue Möglichkeiten zur Code-Härtung: Eine davon ist das Aufdecken von Speicher-Mißmanagement durch den Clang Static Analyzer.

Ein zweites ist das neue Automatic Reference Counting (ARC), welches zur Compile-Zeit Speicherverwaltungsbefehle korrekt in den Code einfügt. Der Entwickler kann die Speichervewaltung also dem Compiler überlassen, ohne die Nachteile einer Garbage-Collection in Kauf zu nehmen, denn ARC ist wie handgeschriebenes Memory-Management, nur zuverlässiger hinsichtlich Korrektheit.

Ein drittes ist, daß der neue Compiler den Fortify Source Patch benutzt, der zur Compilezeit unsichere Speicherverwaltungsbefehle gegen ihr sicheres Pendant austauscht. Damit werden sehr viele potentielle Bufferoverflow-Fehler im Programmcode eliminiert.

Rechtmäßiger

Außerdem wurden die Zugriffsrechte für verschiedene Verzeichnisse stärker abgesichert:

• Diverse Verzeichnisse im Systembereich, die zuvor die Gruppe Admin hatten, haben nun die Gruppe wheel, die die primäre Gruppe von root ist.
• Das oberste Verzeichnis / kann nur noch von root geschrieben werden.
• In das Verzeichnis /Applications/Utilities kann nur noch root schreiben, zuvor konnten es auch Admins.
• In /Library können Admins nicht mehr schreiben. Alle Unterverzeichnisse von /Library können ebenfalls nur noch von root geschrieben werden, außer Caches, Fonts, Java, QuickTimeStreaming, Receipts und Tomcat, die weiterhin von Admins schreibbar sind.
• Die Verzeichnisse /Network/Applications und /Network/Library sind auch von root nicht mehr schreibbar.
• Das Verzeichnis /var/log/DiagnosticMessages darf allerdings seit Lion auch von Admins geschrieben werden.

Das Verzeichnis /lost+found ist nun versteckt. Ebenso $HOME/Library, das unter anderem die Sandboxen der diversen Programme beherbergt. Man kann seine private Library jedoch auch im Finder im "Go" Menüpunkt erreichen, wenn man die alt-Taste gedrückt hält.

Verschlüsselter

Man kann nun das System Root-Volume komplett verschlüsseln. Wenn man das einschaltet, passiert die Verschlüsselung im Hintergrund und man kann normal weiterarbeiten. Wenn sie dann aktiv ist, muß man sich jedesmal erzwungen einloggen, wenn der Rechner aufwacht oder gestartet wurde.

Jetzt einstimmig

Mit Lion ist sind dann auch die letzten Kritikpunkte bezüglich Sicherheit verschwunden. Wir haben die seltene Situation, daß auch die bekannten Hacker schwer begeistert sind von Mac OS X. Und nicht nur das. Lion bietet mit seinem wunderbar einfachen aber effizientem Sandboxing für Apps eine Sicherheit, die alle anderen Plattformen abhängt, hauptsächlich jedoch, weil Apple in der Lage ist, dieses Feature flächendeckend einzuführen dank seines App Stores und der strengen Qualitätskontrolle, die in Kürze auch Sandboxing zwingend erfordert.

Als Beispiel mag die Aussage von Dino Dai Zovi dienen:

Und Charlie Miller sagt:

Nichts mehr mit "Mac hacken macht Spaß", was sie auf ASLR und NX/DEP bezogen hatten.

Ohne Hacker

Durch die Presse geistert gerne die Meldung, Apple habe ein paar Hacker "eingeladen", sich die Prerelease von Lion anzusehen. Es ging jedoch nicht darum, sich reinreden zu lassen.

---