Die Benutzerkontensteuerung hat Microsoft in Windows 7 entschärft. ZDNet zeigt anhand von Exploits, dass sie dadurch zu einem zahnlosen Tiger ohne jede Sicherheitsrelevanz wird - beim gleichzeitigen Erhalt der Kompatibilitätsprobleme.
Mit Windows 7 hat Microsoft einiges an der Benutzerkontensteuerung (UAC) geändert. Anders als in Vista poppt nicht bei jeder kleinen Änderung an den Einstellungen eine Box hoch, die den Benutzer auffordert, die jeweilige Aktion zu bestätigen. Das hat dazu geführt, dass viele Anwender die Benutzerkontensteuerung abgeschaltet haben.
Windows 7 verfolgt ein anderes Konzept: Die Benutzerkontensteuerung lässt sich nicht nur ein- oder ausschalten, sondern ist in mehreren Stufen implementiert, siehe Bild 1[1]. Die höchste Stufe "Always notify" entspricht dem Standard-Verhalten in Windows Vista. Jede Aktion, die Administratorrechte erfordert, bringt eine Bestätigungsbox auf den Desktop.
Die Standard-Einstellung unter Windows 7 ist "Notify me only when programs try to make changes to Windows Settings". Was sich dahinter verbirgt, ist durchaus erklärungsbedürftig: Microsoft geht davon aus, dass Programme, die Bestandteil des Betriebssystems sind, etwa die Systemsteuerung, nicht absichtlich Schaden anrichten. Daher werden diese Programme automatisch mit höheren Rechten versehen, wenn sie ausgeführt werden.
So kann man über die Systemsteuerung oder über die Microsoft-Management-Konsole (MMC) Administrationsaufgaben erledigen, ohne dass der nervige Dialog erscheint, der zur Bestätigung auffordert. Da Windows an der digitalen Signatur erkennen kann, ob es sich tatsächlich um eine Original-Datei handelt, die nicht durch Malware verändert ist, scheint das ein guter Kompromiss zu sein. Die Sicherheit steigt, ohne den Benutzer übermäßig zu nerven.
Leider gibt es Angriffsmöglichkeiten gegen diese UAC-Einstellung. Proof-of-Concept-Exploits[2] zeigen, dass es möglich ist, sich über DLL-Injection in die Original-Windows-Dateien einzuklinken. Mittlerweile ist bekannt, dass die meisten dieser Exploits auch mit der RTM-Version von Windows 7 funktionieren.
Bildergalerie
UAC in Windows 7 einfach aushebeln[3]
» zur Bildergalerie ...[3]ZDNet hat den Proof-of-Concept-Exploit Win7ElevateV2[4] mit der finalen Version von Windows 7 getestet, siehe Bild 2[5]. Damit ist es ohne Probleme möglich, einen Prozess mit allen Administratorrechten zu erzeugen, ohne dass die UAC eine Bestätigungsbox zeigt. Nachahmer seien gewarnt, dass viele Antivirenprogramme das Executable mittlerweile als Malware einstufen[6]. Es besteht allerdings keine ernsthafte Gefahr, da nur eine Kommandozeile mit Administratorrechten geöffnet wird.
Die Einstufung als Malware aufgrund einer signaturbasierten Erkennung ist sicherheitstechnisch praktisch wirklungslos, denn der Sourcecode[7] ist öffentlich. Eine einfache Neukompilierung mit einem anderen Compiler oder mit anderen Optionen führt dazu, dass das Programm nicht mehr entdeckt wird. Malware-Autoren, die diesen Code in ihre Machwerke integrieren, müssen aktuelle Signaturen von Antivirenprogrammen nicht fürchten.
Die überwiegende Anzahl von Malware kommt noch nicht mit der Windows-7-UAC zurecht. Das liegt aber daran, dass Windows 7 noch relativ neu ist. In Zukunft werden Malware-Programmierer damit beginnen, neue Viren zu schreiben, die die Benutzerkontensteuerung in der Standardkonfiguration unbemerkt aushebeln.
Zudem muss man sich im Klaren darüber sein, dass ein großer Teil der Malware überhaupt keine Administratorrechte benötigt und deshalb von der Benutzerkontensteuerung in keiner Weise behindert wird. Dazu gehören etwa alle Botnet-Clients, die im Auftrag ihrer Command-and-Control-Server Spam versenden. Das gleiche gilt für viele Schädlinge, die sich als Extension in einen Browser einklinken.
Zur Verbesserung der Kompatibilität mit älteren Anwendungen, die nichts von der Benutzerkontensteuerung wissen, hat Microsoft in Windows 7 nichts getan. Dabei wäre das nicht schwierig gewesen. Um zu verstehen, wieso Anwendungen oft nicht kompatibel sind - auch wenn man sie mit der Option "Als Administrator ausführen" installiert aufruft - muss man sich etwas tiefer mit den Benutzerrechten von Windows auseinandersetzen.
Anders als bei Unix-Betriebssystemen wie Linux und Mac OS sind die globalen Rechte nicht fest mit einem Superuser-Account wie root verdrahtet, sondern einzelnen Benutzern und Gruppen zugewiesen, siehe Bild 3[8].
Lediglich das SYSTEM-Account, unter dem man sich nicht einloggen kann, besitzt die meisten dieser Rechte automatisch. Seit Windows 2003 sind dem SYSTEM-Account allerdings eine Reihe von Rechten entzogen. Dazu gehört das Recht "Create a process level token" (SeCreateTokenPrivilege).
Die Rechte sind in jedem Prozess-Token hinterlegt. Beim Start eines Prozesses sind sie alle auf disabled gesetzt. In allen Windows-Version seit Windows NT 3.1 führt das Ändern von Datum und Uhrzeit zu einem Access-Denied-Fehler, weil das Recht "Change the system time" (SeChangeTimePrivilege) nicht aktiviert ist. Ein vorhandenes globales Recht kann ein Prozess jedoch einfach ohne jede Authentifizierung anfordern. Das dient vor allem Dokumentationszwecken im System-Event-Log. Disabled bedeutet nicht, dass das Recht nicht genutzt werden kann.
Seit Windows 2000 gibt es die Möglichkeit mit der API-Funktion CreateRestrictedToken[9] ein Security-Token zu generieren, das eine Kopie des aktuellen Token ist. Es lassen sich jedoch einzelne Rechte oder Gruppenmitgliedschaften entfernen. Ein Tochterprozess, der mit diesem Token erzeugt wurde, kann die entfernten Rechte und Gruppenmitgliedschaften weder anfordern noch nutzen.
Mit der CreateRestrictedToken-Funktion lässt sich eine Art Mini-Benutzerkontensteuerung realisieren. Für Windows XP gibt es beispielsweise das Programm DropMyRights[10], was diese Funktionalität nutzt, in dem es aus dem Restricted Token die Administratorgruppe entfernt. Allerdings ist es auf diese Weise nicht möglich, einmal freiwillig abgegebene Rechte wieder zurückzuholen. Würde man DropMyRights auf die Explorer-Shell anwenden, hätten alle gestarteten Programme nur die eingeschränkten Rechte.
Um die verlorenen Rechte wiederzuerlangen, ist ein neues Logon bei der LSA[11] erforderlich. Dadurch verlieren Tochterprozesse jedoch ihre Credentials. Somit ist es insbesondere nicht mehr möglich auf Netzwerklaufwerke zuzugreifen. Temporär gemountete Netzlaufwerke, sind im Tochterprozess gar nicht sichtbar. Permanent gemountete (Option "Reconnect at Logon") sind zwar sichtbar aber nicht nutzbar. Bild 4[12] zeigt, dass die Administrator-Konsole nur das permanente Laufwerk Y: besitzt, auf das sich aber mittels dir nicht zugreifen lässt.
So wird unmittelbar klar, dass bestimmte Dinge nicht funktionieren: Anwendungen, die nicht "UAC-aware" sind, jedoch Administratorrechte benötigen, kann man nur mit der Option "Als Administrator ausführen" starten. Sie haben dann jedoch keine Netzwerklaufwerke und andere Fernressourcen, etwa Drucker oder Named Pipes[13], zur Verfügung.
Grundsätzlich ist es natürlich aus Sicherheitserwägungen richtig, Prozesse, die über ein erneutes Logon ein neues Token erhalten, nicht mit den Credentials eines anderen Prozesses auszustatten. Jedoch hätte Microsoft einen Mechanismus schaffen müssen, der es erlaubt, ein Token zu erzeugen, das die verlorengegangenen Rechte eines Mutterprozesstokens zurückerhält, ohne dazu einen Logon durchzuführen. Das hätte man mit einer Bestätigung über den Secure Desktop[14] absichern können.
Man könnte argumentieren, dass dies zu gefährlich ist, weil es seinen Grund hat, dass Tochterprozesse sich keine einmal entzogenen Rechte zurückholen dürfen. Da es die Benutzerkontensteuerung in der Standardeinstellung jedoch erlaubt, ohne Eingabe des Passworts ein neues Logon bei der LSA durchzuführen, sind beide Möglichkeiten sicherheitstechnisch gleich gefährlich. So hätte Microsoft die Inkompatibilitäten mit älteren Programmen bei der Benutzerkontensteuerung vermeiden können.
Die neue Benutzerkontensteuerung von Windows 7 poppt zwar nicht bei jeder Kleinigkeit hoch, bietet dafür aber kaum noch Sicherheit. Exploits, die im Internet als Sourcecode vorliegen, können von jedem Malware-Autor leicht in jeden Schädling, der Administratorrechte benötigt, eingebaut werden.
Microsoft hat auf diese Exploits sogar reagiert. Wie so oft anwortete das Unternehmen mit "This is by design[15]". Das ist die Standardaussage, wenn Microsoft einen Fehler nicht eingestehen will.
Was Kompatibilität mit Anwendungen angeht, die nicht "UAC-aware" sind, hat Microsoft im Vergleich zu Vista keine Verbesserungen eingebaut. Viele Programme funktionieren auch dann nicht, wenn man mit der Option "Als Administrator ausführen" startet. Dabei wäre nur wenig konzeptionelle Arbeit erforderlich gewesen, die Kompatibilität herzustellen.
Für solche Programme bleibt in Windows 7 nur der sogenannte XP-Mode[16], der auf einer Virtualisierungslösung mit dem noch nicht erschienenen Virtual PC 7 beruht. Programme, die Zugriff Hardware benötigen, die nicht an einen USB-Port angeschlossen ist, etwa eine TV-PCI-Karte, lassen sich jedoch auch auf diese Weise nicht betreiben.
Aufgrund des nur äußerst geringen Sicherheitsgewinns durch die Benutzerkontensteuerung von Windows 7 in der Standardeinstellung sollte man überlegen, die UAC komplett abzuschalten. So ist zumindest die Kompatibilität der meisten Anwendungen für Windows XP sichergestellt. Wer die Benutzerkontensteuerung tatsächlich aus Sicherheitsgründen einsetzen möchte, sollte sie allerdings auf die höchste Stufe einstellen. Ein Aufpoppen bei jeder Kleinigkeit wie unter Vista ist dabei unausweichlich.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/
[16] = http:/