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

0.9 UAC, das Sicherheits-Plazebo

Stichwort-Liste

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.

Mark Russinovich, Microsoft Technet:

Es sollte nun klar sein, daß weder die UAC-Rechteerhöhungen, noch der abgesicherte Modus des IE neue Windows-Sicherheitsschranken definieren. Microsoft hat dies zwar so kommuniziert, aber ich will sicherstellen, daß dies deutlich wird.

It should be clear then, that neither UAC elevations nor Protected Mode IE define new Windows security boundaries. Microsoft has been communicating this but I want to make sure that the point is clearly heard.

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.

Microsoft, MSDN-Dokumentation:

… der Integritäts-Mechanismus kann keine vollständige Isolationsbarriere zur Verfügung stellen. Der Windows Integritäts-Mechanismus ist nicht als Sandbox für Programme gedacht.

… the integrity mechanism cannot provide a complete isolation barrier. The Windows integrity mechanism is not intended as an application sandbox.

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?

Mark Russinovich, Microsoft Technet:

Es ist wichtig zu wissen, daß UAC-Rechteerhöhungen Annehmlichkeiten (Komfort) sind und keine Sicherheits-Schranken. Eine Sicherheits-Schranke würde nämlich erfordern, daß irgendeine Sicherheits-Richtlinie vorschreibt, was diese Schranke passieren darf. … Weil die Erhöhungen keine Sicherheits-Schranken sind, könnte es vorkommen, daß Schadprogramme, die auf dem System mit Standard-Benutzer-Rechten laufen, einen erhöhten Prozeß kompromittieren, um administrative (Sytem-) Rechte zu erlangen. … Erhöhungs-Dialoge nennen lediglich das Programm, das erhöht werden soll; … Das Programm wird jedoch Kommandozeilen-Argumente verarbeiten, dynamische Bibliotheken laden, Dateien öffnen und mit anderen Prozessen kommunizieren. Jede dieser Operationen kann Schadprogrammen ermöglichen, den erhöhten Prozeß zu kompromittieren und dadurch administrative (System-) Rechte zu bekommen.

It’s important to be aware that UAC elevations are conveniences and not security boundaries. A security boundary requires that security policy dictates what can pass through the boundary. … Because elevations aren’t security boundaries, there’s no guarantee that malware running on a system with standard user rights can’t compromise an elevated process to gain administrative rights. … elevation dialogs only identify the executable that will be elevated; … The executable will process command-line arguments, load DLLs, open data files, and communicate with other processes. Any of those operations could conceivably allow malware to compromise the elevated process and thus gain administrative rights.

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.

Mark Russinovich, Microsoft Technet:

… Schadprogramme können gemeinsam genutzte Speicher-Objekte für sich ausnutzen, indem sie eines, das beispielsweise von einer erhöhten Anwendung verwendet wird, kapern und damit zuerst diese Anwendung kompromittieren und anschließend das System.

… shared memory objects. Malware could take advantage of that sharing to hijack a shared memory object used by an elevated application, for instance, to compromise the application and then the system.

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.

Mark Russinovich, Microsoft Technet:

Der Windows Integritäts-Mechanismus funktioniert nicht über das Netzwerk. Wenn eine Standard-Benutzer-Anwendung unter einem "geschützten" Administrator läuft, dann hat sie Zugriff auf die System-Ressourcen eines Systems im Netzwerk, auf dem dieser "geschützte" Administrator administrative (System-) Rechte hat. Wenn man diesen Mißstand beheben wollte, hätte das größere Kompatibilitätsprobleme für Programme zur Folge.

Windows Integrity Mechanism also doesn't flow across the network. A standard user application running in a PA account will have access to system resources on a remote system on which that PA account has administrative rights. Addressing these limitations has major application compatibility ramifications.

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".

Mark Russinovich, Microsoft Technet:

Es ist für Dritt-Programme, die unter einem "geschützten" Administrator mit Standard-Benutzer-Rechten laufen, möglich, die automatische Rechteerhöhung zu nutzen, um administrative (System-) Rechte zu erlangen. Beispielsweise kann das Programm mit der WriteProcessMemory API beliebigen Code in den Speicher des Explorers schreiben und mit der CreateRemoteThread API diesen Code dann ausführen … Schadprogramme können mit der gleichen Technik an administrative (System-) Rechte kommen.

… it's possible for third-party software running in a PA account with standard user rights to take advantage of auto-elevation to gain administrative rights. For example, the software can use the WriteProcessMemory API to inject code into Explorer and the CreateRemoteThread API to execute that code … malware could gain administrative rights using the same techniques.

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.

Siehe dazu auch:

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.

Stille Rechte-Erhöhung

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.

Valid XHTML 1.0!

Besucherzähler


Latest Update: 11. September 2015 at 19:51h (german time)
Link: www.macmark.de/windows_uac_security_placebo.php
Backlinks-Statistik deaktiviert; kann rechts im Menü eingeschaltet werden.