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

0.9 UAC, das Sicherheits-Plazebo

Stichwort-Liste

• 0.9.1 Einleitung
• 0.9.2 Keine Sandbox
• 0.9.3 Keine Sicherheitsschranke
• 0.9.4 Keine Netzwerk-Sicherheit
• 0.9.5 Windows 7 serienmäßig mit Local-Root-Exploit
• 0.9.6 Beispiel für Ausnutzung der stillen Rechte-Erhöhung unter Windows 7
• 0.9.7 Behinderung für Schädlinge?
• 0.9.8 Auswege

0.9.1 Einleitung

Die UAC wird oft fälschlicherweise als eine Sicherheitsfunktion wahrgenommen. Ich erkläre hier, basierend auf original Microsoft-Informationen, daß sie ähnlich einem Plazebo nur die gefühlte Sicherheit erhöht. Denn technisch ist sie nicht in der Lage, das zu halten, was sich manche Anwender von ihr bezüglich Sicherheit versprechen. Microsoft hatte solche Hoffnungen als Verkaufsargument geweckt.

Wozu dient die UAC denn sonst? Microsoft möchte, daß sich die Software-Hersteller daran gewöhnen, daß ihre Programme nicht mehr damit rechnen können, unter administrativen (System-) Rechten zu laufen. Bislang setzten viele Programme, auch von Microsoft selbst, solche Rechte als gegeben voraus. Auf UNIX-Systemen wie OS X setzen die üblichen Benutzer-Programme hingegen keine System-Rechte voraus. Um abwärtskompatibel zu bleiben, scheut Microsoft den harten Schritt, Programme mit unterschiedlichen Rechte-Bedürfnissen auch nur unter unterschiedlich berechtigten Benutzern laufen zu lassen.

0.9.2 Keine Sandbox

Eine Sandbox sperrt einen Prozeß so ein, daß er nicht ausbrechen kann. Das können die Integritätsstufen von Windows jedoch schon allein aus dem Grund nicht leisten, weil sie einzelne Prozesse nicht voneinander isolieren, sondern in Gruppen einteilen. Innerhalb jeder Gruppe kann wie gehabt kommuniziert werden.

Für Google waren diese Integritätsstufen beispielsweise nicht brauchbar, um sie für den Google Chrome Browser zu nutzen. Dieser läßt die Darstellung jeder Seite in einem eigenen Prozeß laufen, um sie voneinander zu isolieren. Es gibt vier Integritätsstufen: "System", "Hoch", "Mittel" und "Niedrig". Es kann jedoch von oben nach unten und innerhalb einer Stufe kommuniziert werden. Also ist eine Isolation nur in eine Richtung, von unten nach oben, gegeben. Wie will man jedoch beispielsweise fünf Google Chrome Browser-Tabs damit voreinander schützen? Dies ist aus mehreren Gründen mit den Integritätsstufen unmöglich. Wenn man alle in "Niedrig" laufen läßt, gibt es keinen Schutz voreinander. In "Hoch" dürfen sie das System beeinflussen. Die Anzahl reicht auch nicht, um jedem Fenster eine eigene Stufe zu spendieren. Und die Stufen sind nur in eine Richtung "dicht". Aber auch das nicht wirklich, wie wir noch sehen werden.

0.9.3 Keine Sicherheitsschranke

Der typische Windows-Vista/7-Benutzer arbeitet weiterhin als System-Administrator. Microsoft bestärkt dies noch, indem durch den sogenannten "geschützten" Administrator suggeriert wird, daß dem System nichts passieren kann, weil er hauptsächlich Prozesse mit normalem Rechten am Laufen hat und diese die höherprivilegierten nicht beeinflussen könnten. Das ist jedoch nicht der Fall.

Der Unterschied zu früheren Windows-Version ist lediglich, daß der "geschützte" Administrator zwei Rechte-Token hat: Eines mit vollen Rechten und eines mit normalen Rechten. Beide Rechte-Tokens dieses Benutzers sind jedoch miteinander verbunden, weil sie tatsächlich zu demselben Benutzer und zur selben Login-Session gehören.

Die Programme des "geschützten" Administrators benutzen diverse gemeinsame Resourcen und kommunizieren miteinander. Der Benutzer würde sich auch wundern, wenn er mit einem erhöhten Programm nicht genauso arbeiten könnte wie mit einem unter normalen Rechten. Daher nimmt ein "erhöhtes" Programm auch Parameter aus dem "normalen" Bereich an, lädt gemeinsam genutzte Erweiterungen und Bibliotheken, liest von Programmen unter normalen Rechten geschriebene Dateien ein und kommuniziert mit anderen Programmen des Benutzers. Wie würde ein Benutzer reagieren, wenn Kopieren und Einfügen nicht mehr funktioniert zwischen seinen normalen und erhöhten Programmen?

Zudem verwenden die erhöhten Programme gemeinsam mit nicht-erhöhten Programmen des Benutzers gemeinsame Speicher-Objekte. Ein Schädling, der als nicht-privilegiertes Programm läuft, kann darüber privilegierte Programme des Benutzers beeinflussen und problemlos Systemrechte nutzen.

0.9.4 Keine Netzwerk-Sicherheit

Windows wird auch wieder eingeholt von seiner Netzwerk-Sicherheits-ignoranten Vergangenheit: Um Kompatibilitätsprobleme zu vermeiden, ist es einem nicht-privilegiertem Programm unter einem "geschützten" Administrator möglich, über das Netzwerk auf einem anderen Rechner mit Systemrechten zu arbeiten.

0.9.5 Windows 7 serienmäßig mit Local-Root-Exploit

Ich hatte es ja schon lange vorher in meinem Blog erwähnt. Eine Dokumentation dieser Eigenschaft steht aber auch ganz offiziell bei Microsoft zur Verfügung.

Ein Programm mit normalen Benutzer-Rechten kann unter Windows 7 über offizielle Programmierschnittstellen und "by design" an Systemrechte kommen. Zu verdanken ist das einigen von Microsoft mitgelieferten Standardprogrammen wie dem Explorer, die die Erlaubnis haben, bei Bedarf Systemrechte zu nutzen. Ein Schadprogramm braucht diese Programme von der weißen Liste nur "um Hilfe bitten".

0.9.6 Beispiel für Ausnutzung der stillen Rechte-Erhöhung unter Windows 7

Leo Davidson hat ein Beispiel für die Nutzung der stillen Rechte-Erhöhung geschrieben. Es ist eine ausführbare Datei, die als normaler nicht-erhöhter Prozeß gestartet wird. Er hat dies von Grund auf in nur anderthalb Tagen programmiert, wobei er ausdrücklich darauf hinweist, daß er zwar ein erfahrener Windows-Entwickler, aber kein Sicherheits-Forscher oder Hacker sei, er also dergleichen nicht jeden Tag schreibt.

Der Proof-of-Concept funktioniert, indem zuerst der Prozeß einen Teil von sich in den Speicher eines anderen Prozesses kopiert und diesen dann dort ausführen läßt. Dies wird durch nicht-privilegierte Standard-Programmierschnittstellen umgesetzt wie WriteProcessMemory und CreateRemoteThread, deren Nutzung auch von Anti-Viren-Programmen nicht verhindert werden kann. Als Zielprozeß wird einer gewählt, der auf der weißen Liste steht und für bestimmte von ihm erzeugte COM-Objekte erhöhte Rechte anfordern darf, ohne daß unter den Standard-Einstellungen von Windows 7 eine UAC-Nachfrage kommt. Andere Programme auf der weißen Liste bekommen sogar ohne Nachfrage als Ganzes erhöhte Rechte, wenn sie sie anfordern.

Nachdem der Code im Weiße-Liste-Zielprozeß läuft, wir als nächstes von ihm ein COM-Objekt mit erhöhten Rechten angefordert. Das System gewährt dies ohne Nachfragen, weil der Prozeß auf der weißen Liste steht. Damit hat man nun eigenen Wunsch-Code unter erhöhten Rechten am Laufen.

Es gibt noch andere Wege, Code in den Zielprozeß zu bringen, wie die Ausnutzung von Speicherüberläufen oder die Installation als Plugin-DLL, die das Zielprogramm lädt, wie im Falle von Explorer Shell-Extensions. Leo hat Code-Injizierung gewählt, weil man damit den Code leichter in das Zielprogramm bekommt ohne herumtricksen zu müssen. Leo betont, daß dies kein Hack ist, weil lediglich dokumentierte und offiziell unterstützte Funktionen benutzt werden, die nicht einmal selbst erhöhte Rechte benötigen, um zu funktionieren.

Ich habe sein Programm auf einem aktualisierten Windows 7 ausprobiert und damit den Explorer gebeten, mir eine Administrator-Eingabeaufforderung zu erstellen. Mit der konnte ich dann im System Änderungen vornehmen, die unter diesen Standardeinstellungen sofort zu einer UAC-Nachfrage führen müßten. Aber das passiert nicht dank der weißen Liste.

0.9.7 Behinderung für Schädlinge?

Ist die UAC ein Hindernis für Schädlinge? Nicht viel mehr als für jedes andere nicht an die neue Situation angepaßte Programm auch. Schädlinge konnten ebenfalls bisher davon ausgehen, direkt im System herumpfuschen zu können, weil in der Regel jedes Programm vor Vista Systemrechte hatte.

Diese Systemrechte bekommt man nun nicht mehr aufgedrängt, sondern muß sie sich selbst besorgen. Im Gegensatz zu UNIX ist dafür jedoch kein gravierender Systemfehler nötig, sondern lediglich die Nutzung offizieller Programmierschnittstellen und der absichtlich in Windows 7 eingebauten Menge von Programmen, die von Microsoft eine Erlaubnis zur automatischen Rechte-Erhöhung spendiert bekommen haben.

Zusätzlich kann ein Schädling noch davon profitieren, daß privilegierte Prozesse und solche ohne Systemrechte unter dem typischen Benutzer auf Vista und 7 nicht voneinander getrennt werden können und laut Dokumentation auch nicht voneinander getrennt werden sollen, da es bei der UAC um Bequemlichkeit und nicht um Sicherheit geht. Es war eine Design-Entscheidung von Microsoft, wieder einmal Bequemlichkeit und Abwärtskompatibilität gegenüber der Sicherheit und einem klaren Trennungschritt von der Vergangenheit den Vorzug zu geben.

0.9.8 Auswege

Reale Sicherheit bietet ein Verzicht auf UAC. Stattdessen sollte man den schnellen Benutzerwechsel nutzen, da damit kritische von unkritischen Prozessen besser getrennt sind, weil sie unter verschiedenen Benutzern laufen. Nach der Erledigung der kritischen Aufgabe muß dann zurück gewechselt werden. Microsoft hat UAC eingeführt, weil sie glauben, der Benutzer würde nicht zurückwechseln.

Bei OS X laufen keine Prozesse unterschiedlicher Wichtigkeit unter demselben Benutzer. Wenn ein Prozeß mit Systemrechten nötig wird, dann wird er unter einem anderen Benutzer (root) gestartet als der gerade arbeitende Benutzer. Ein Einloggen (oder schneller Benutzerwechsel) auf root ist jedoch nicht notwendig und würde auch zuviele zusätzliche Risiken bergen. Daher ist ein Anmelden als root unter OS X auch deaktiviert.

---