Benutzerkontensteuerung (UAC)

Einblick in die Windows 7-Benutzerkontensteuerung

Mark Russinovich

Kurz zusammengefasst:

• Standardbenutzerkonten
• Benutzerkontensteuerung

Inhalt

Benutzerkontensteuerungstechnologien
Berechtigungserweiterungen und Malware-Sicherheit
Was ist anders in Windows 7?
Automatische Berechtigungserweiterung
Automatische Berechtigungserweiterung und Ziele der Benutzerkontensteuerung

Standardbenutzerkonten ermöglichen höhere Sicherheit und geringere Gesamtbetriebskosten in privaten und Unternehmensumgebungen. Wenn Benutzer mit Standardbenutzerrechten anstelle von Administratorrechten arbeiten, ist die Sicherheitskonfiguration des Systems, einschließlich Antivirus und Firewall, geschützt. Benutzer verfügen so über einen sicheren Bereich, der ihr Konto und das übrige System schützen kann. Bei Bereitstellungen in Unternehmen lassen sich die von Desktop-IT-Managern festgelegten Richtlinien nicht überschreiben, während auf einem gemeinsam genutzten Familiencomputer Benutzerkonten vor Änderungen geschützt sind, die von anderen Konten durchgeführt werden.

Unter Windows hat das Arbeiten mit Administratorrechten jedoch eine lange Tradition. Software wurde daher oft so entwickelt, dass sie zur Ausführung ein Administratorkonto verwendet und - häufig unabsichtlich - von Administratorrechten abhängt. Die Benutzerkontensteuerung (User Account Control, UAC) wurde unter Windows Vista eingeführt, damit mehr Software mit Standardbenutzerrechten ausgeführt werden kann, und um Entwickler beim Schreiben von Anwendungen zu unterstützen, die problemlos mit Standardbenutzerrechten ausgeführt werden können. UAC kombiniert Technologien wie Dateisystem- und Registrierungsvirtualisierung, das geschützte Administratorkonto (Protected Administrator, PA), UAC-Eingabeaufforderungen zur Berechtigungserweiterung und Windows Integrity-Ebenen, die diese Ziele unterstützen. In meinen Konferenzpräsentationen und im TechNet Magazine-Artikel zu UAC-Interna habe ich das ausführlich behandelt.

Windows 7 bringt die UAC-Ziele einen Schritt weiter, wobei sich die zu Grunde liegenden Technologien kaum geändert haben. Es werden jedoch zwei neue Modi eingeführt, in denen das UAC-PA-Konto arbeiten kann, sowie ein Mechanismus zur automatischen Berechtigungserweiterung für einige integrierte Windows-Komponenten. In diesem Beitrag behandele ich den Sinn von UAC-Technologien, untersuche erneut die Beziehungen zwischen UAC und Sicherheit, beschreibe die zwei neuen Modi und erläutere, wie die automatische Berechtigungserweiterung genau funktioniert. Beachten Sie, dass sich die Informationen in diesem Beitrag auf das Verhalten des Windows 7-Release Candidate beziehen, der sich in vielen Punkten von der Betaversion unterscheidet.

UAC-Technologien

Das wichtigste Element und der direkte Vorteil der UAC-Technologie besteht darin, dass er Windows für Standardbenutzer einfacher macht. Als exemplarisches Beispiel soll der Unterschied zwischen den Berechtigungsanforderungen zum Einstellen der Zeitzone unter Windows XP und Windows Vista dienen. Unter Windows XP erfordert die Änderung der Zeitzone ‑ sogar die Anzeige der Zeitzone mit dem Systemsteuerungsapplet Datum/Uhrzeit ‑ Administratorrechte.

Dies liegt daran, dass Windows XP nicht zwischen dem Ändern der Uhrzeit, einem sicherheitsrelevanten Systemvorgang, und dem Ändern der Zeitzone, die lediglich die Art und Weise, wie die Uhrzeit angezeigt wird, beeinflusst, unterscheidet. In Windows Vista (und Windows 7) ist die Änderung der Zeitzone kein Administratorvorgang, und das Systemsteuerungsapplet Datum/Uhrzeit trennt Administratorvorgänge von Standardbenutzervorgängen. Allein diese Änderung ermöglicht es vielen Unternehmen, Mitarbeiter auf Reisen mit Standardbenutzerkonten zu konfigurieren, weil diese die Zeitzone ihrem momentanen Standort anpassen können. Windows 7 geht einen Schritt weiter, indem zum Beispiel die Aktualisierung der IP-Adresse des Systems, die Verwendung von Windows Update zur Installation optionaler Updates und Treiber, die Änderung der Bildschirmauflösung und die Anzeige der aktuellen Firewalleinstellungen auch Standardbenutzern zur Verfügung stehen.

Dateisystem- und Registrierungsvirtualisierung arbeiten im Hintergrund, um vielen Anwendungen, die unabsichtlich Administratorrechte verwenden, eine ordnungsgemäße Ausführung ohne solche Rechte zu ermöglichen. Besonders häufig werden Administratorrechte unnötigerweise bei der Speicherung von Anwendungseinstellungen oder Benutzerdaten in Bereichen der Registrierung oder des Dateisystems, die zur Nutzung durch das System bestimmt sind, verwendet. Einige Legacy-Anwendungen speichern beispielsweise ihre Einstellungen im systemweiten Teil der Registrierung (HKEY_LOCAL_MACHINE\Software) statt im benutzerspezifischen Teil (HKEY_CURRENT_USER\Software). Bei der Registrierungsvirtualisierung werden Versuche, in den Systembereich zu schreiben, in Schreibvorgänge in HKEY_CURRENT_USER (HKCU) geändert, wobei die Anwendungskompatibilität halten bleibt.

Das PA-Konto soll Entwickler motivieren, ihre Anwendungen so zu schreiben, dass sie nur Standardbenutzerrechte benötigen, während weiterhin möglichst viele Anwendungen, die den Status zwischen Administratorkomponenten und Standardbenutzerkomponenten teilen, funktionieren. Standardmäßig ist das erste Konto auf einem Windows Vista- oder Windows 7-System, das in früheren Versionen von Windows ein reines Administratorkonto war, ein PA-Konto. Alle Programme, die ein PA-Benutzer ausführt, werden mit Standardbenutzerrechten ausgeführt, sofern der Benutzer nicht ausdrücklich die Berechtigung für die Anwendung erweitert. Dann erhält die Anwendung Administratorrechte. Eingabeaufforderungen zur Berechtigungserweiterung werden von Benutzeraktivitäten wie beispielsweise der Installation von Anwendungen und Änderung von Systemeinstellungen ausgelöst. Diese Eingabeaufforderungen zur Berechtigungserweiterung sind der sichtbarste Teil der UAC-Technologie. Sie äußern sich in der Umschaltung zu einem Bildschirm mit einer Zulassen/Abbrechen-Abfrage und einem abgeblendeten Schnappschuss des Desktops als Hintergrund.

Im Anschluss an die Installation erstellte Konten sind standardmäßig Standardbenutzerkonten mit der Möglichkeit, ihre Berechtigungen mithilfe einer Eingabeaufforderung zu erweitern, die nach Anmeldeinformationen eines Administratorkontos fragt, das zur Erteilung von Administratorrechten verwendet wird. Dadurch können Familienmitglieder, die einen privaten Computer gemeinsam nutzen, oder sicherheitsbewusstere Benutzer, die ein Standardbenutzerkonto verwenden, Anwendungen mit Administratorrechten ausführen, sofern sie das Kennwort für ein Administratorkonto kennen, ohne manuell zu einer anderen Benutzersitzung wechseln zu müssen. Häufige Beispiele solcher Anwendungen sind Installationsprogramme und Jugendschutzeinstellungen.

Wenn UAC aktiviert ist, arbeiten alle Benutzerkonten – einschließlich Administratorkonten – mit Standardbenutzerrechten. Dies bedeutet, dass Anwendungsentwickler berücksichtigen müssen, dass ihre Software standardmäßig keine Administratorrechte hat. Dadurch soll erreicht werden, dass sie ihre Anwendung so entwerfen, dass diese mit Standardbenutzerrechten funktioniert. Wenn die Anwendung oder Teile davon Administratorrechte benötigt, kann sie den Erweiterungsmechanismus verwenden, damit der Benutzer diese Funktion freigeben kann. Anwendungsentwickler müssen im Allgemeinen nur geringfügige Änderungen an ihren Anwendungen vornehmen, damit diese problemlos mit Standardbenutzerrechten funktionieren. Wie der E7-Weblogbeitrag zu UAC zeigt, beeinflusst UAC erfolgreich die Art und Weise, wie Entwickler Software schreiben.

Eingabeaufforderungen zur Berechtigungserweiterung haben außerdem den Vorteil, dass sie den Benutzer informieren, wenn die Software Änderungen am System vornehmen möchte. So hat der Benutzer die Möglichkeit, dies zu verhindern. Wenn beispielsweise ein Softwarepaket, dem der Benutzer nicht traut oder dem er die Änderung des Systems nicht erlauben möchte, nach Administratorrechten fragt, kann er die Aufforderung ablehnen.

Berechtigungserweiterungen und Malware-Sicherheit

Primäres Ziel von UAC ist es, mehr Benutzern die Arbeit mit Standardbenutzerrechten zu ermöglichen. Eine spezielle UAC-Technologie erweckt jedoch den Anschein eines Sicherheitsfeatures: die Zustimmungsaufforderung. Viele dachten, dass die Tatsache, dass die Software den Benutzer bitten musste, ihr Administratorrechte zu erteilen, bedeutet, dass sich Malware keine Administratorrechte beschaffen kann. Außer der Annahme, dass eine Eingabeaufforderung lediglich für den beschriebenen Vorgang ein „Tor“ zu Administratorrechten ist, scheint der Wechsel zu einem anderen Desktop für das Dialogfeld zur Berichtigungserweiterung und die Verwendung von Windows Integrity Mechanism (WIM) einschließlich User Interface Privilege Isolation (UIPI) diese Annahme zu unterstützen.

Wie wir bereits vor dem Start von Windows Vista immer gesagt hatten, ist der primäre Zweck der Berechtigungserweiterung nicht Sicherheit, sondern Bequemlichkeit: Wenn Benutzer zur Durchführung von Administratorvorgängen das Konto wechseln müssten, indem sie sich bei einem Administratorkonto anmeldeten oder die Schnelle Benutzerumschaltung zu einem Administratorkonto verwendeten, würden die meisten Benutzer einmal umschalten und nicht zurückschalten. Es gäbe auch keinen Fortschritt bei der Änderung der Umgebung, für die Anwendungsentwickler Software schreiben. Wozu dienen also der sichere Desktop und Windows Integrity Mechanism?

Der Hauptgrund für den Wechsel zu einem anderen Desktop für die Eingabeaufforderung besteht darin, dass Standardbenutzersoftware die Eingabeaufforderung zur Berechtigungserweiterung nicht fälschen kann, indem sie beispielsweise den Namen des Herausgebers in Dialogfeld überschreibt, um einen Benutzer glauben zu machen, dass Microsoft oder ein anderer Softwarehersteller die Eingabeaufforderung generiert hat. Der alternative Desktop wird „sicherer Desktop“ genannt, weil er im Besitz des Systems statt des Benutzers ist, genau wie der Desktop, auf dem das System das Windows-Anmeldedialogfeld anzeigt.

Die Verwendung eines anderen Desktops erfolgt auch aus einem anderen wichtigen Grund, der Anwendungskompatibilität: Während integrierte Software zur erleichterten Bedienung, wie die Bildschirmtastatur, gut auf einem Desktop funktioniert, der Anwendungen im Besitz von anderen Benutzern ausführt, gibt es Software anderer Hersteller, für die das nicht gilt. Diese Software würde nicht richtig funktionieren, wenn ein Dialogfeld zur Berechtigungserweiterung, das im Besitz des lokalen Systemkontos ist, auf einem Desktop angezeigt wird, der im Besitz eines Benutzers ist.

Windows Integrity Mechanism und UIPI wurden entwickelt, um eine Schutzmauer um Anwendungen zu errichten, die mit erweiterten Berechtigungen ausgeführt wird. Eines der ursprünglichen Ziele war es, Softwareentwickler daran zu hindern, aus Vereinfachungsgründen bereits mit erweiterten Berechtigungen ausgeführte Anwendungen zur Durchführung von Administratoraufgaben zu nutzen. Eine Anwendung, die mit Standardbenutzerrechten ausgeführt wird, kann keine künstlichen Maus- oder Tastatureingaben an eine Anwendung mit erweiterten Berechtigungen senden, damit diese nach ihren Wünschen arbeitet, oder Code in eine Anwendung mit erweiterten Berechtigungen einschleusen, um Administratorvorgänge durchzuführen.

Windows Integrity Mechanism und UIPI wurden in Windows Vista für den geschützten Modus von Internet Explorer verwendet. So war es für Malware, die eine ausgeführte Instanz von IE infiziert hatte, schwieriger, Benutzerkontoeinstellungen zu modifizieren, um sich selbst beispielsweise so zu konfigurieren, dass sie bei jeder Benutzeranmeldung gestartet wird. Während es zu Beginn ein Designziel von Windows Vista war, Berechtigungserweiterungen in Verbindung mit dem sicheren Desktop, Windows Integrity Mechanism und UIPI zu verwenden, um eine undurchdringliche Barriere (die so genannte Sicherheitsgrenze) zwischen Software, die mit Standardbenutzerrechten und Administratorrechten ausgeführt wird, zu schaffen, machten es zwei Gründe unmöglich, dieses Ziel zu erreichen, sodass es später fallen gelassen wurde: Nutzbarkeit und Anwendungskompatibilität.

Abbildung 1 Anzeige des Namens der ausführbaren Datei

Schauen wir uns zunächst das Dialogfeld zur Berechtigungserweiterung selbst an. Es zeigt den Namen und Herausgeber der primären ausführbaren Datei an, der Administratorrechte erteilt werden sollen. Zwar signieren immer mehr Softwarehersteller ihren Code digital, doch gibt es Software, insbesondere ältere Anwendungen, die nicht signiert ist. Bei nicht signierter Software zeigt das Dialogfeld zur Berechtigungserweiterung lediglich den Namen der ausführbaren Datei an. So kann Malware, die bereits in einem Benutzerkonto ausgeführt wird und auf die Erweiterung der Berechtigung eines nicht signierten Anwendungsinstallationsprogramms namens Setup.exe wartet, beispielsweise die ausführbare Datei durch eine böswillige Setup.exe ersetzen, ohne dass der Benutzer dies merkt (siehe Abbildung 1).

Das Dialogfeld sagt dem Benutzer außerdem nicht, welche DLLs die ausführbare Datei beim Start lädt. Wenn sich die ausführbare Datei in einem Verzeichnis unter der Kontrolle des Benutzers befindet, kann Malware, die mit den Standardrechten des Benutzers ausgeführt wird, alle zugehörigen DLLs an dem Ort, den die Software verwenden wird, ersetzen. Alternativ könnte Malware parallele Funktionen verwenden, damit die ausführbare Datei böswillige Versionen von Anwendungs- oder System-DLLs lädt. Und außer wenn ein Benutzer vorsichtshalber auf die Schaltfläche Details anzeigen klickt und den für die erweiternde ausführbare Datei aufgelisteten Dateipfad sorgfältig prüft, kann Malware die ausführbare Datei an einen Ort mit ähnlichem Namen (z. B. \ProgramFiles\Hersteller\Anwendung.exe statt \Program Files\Hersteller\Anwendung.exe; beachten Sie das fehlende Leerzeichen in „ProgramFiles“) kopieren, an dem sie kontrollieren kann, welche DLLs von der Anwendung geladen werden. In Abbildung 2 habe ich eine Komponente von Microsoft Network Monitor in das selbst erstellte Verzeichnis C:\ProgramFiles, das vom Benutzer kontrolliert werden kann, kopiert und gestartet.

Abbildung 2 Kopie von Microsoft Network Monitor-Komponente wird gestartet

Zur Anwendungskompatibilität nutzen Anwendungen mit erweiterter Berechtigung außerdem einen erheblichen Teil des Systems gemeinsam mit der Standardbenutzerumgebung, sodass eine böswillige Anwendung das Verhalten einer Anwendung mit erweiterter Berechtigung beeinflussen kann. Besonders deutlich wird dies am Beispiel des Registrierungsprofils des Benutzers, HKEY_CURRENT_USER (HKCU). Es wird gemeinsam genutzt, weil Benutzer von Einstellungen und Erweiterungen, die sie als Standardbenutzer registrieren, erwarten, dass diese auch in Anwendungen mit erweiterter Berechtigung funktionieren. Malware könnte in HKCU registrierte Shell-Erweiterungen nutzen, um sich in Anwendungen mit erweiterter Berechtigung zu laden, die Suchen-Dialogfelder der Shell wie Datei öffnen oder Datei speichern verwenden. Auch andere Bereiche werden gemeinsam genutzt, insbesondere der Base Named Object-Namespace, in dem Anwendungen Synchronisierungs- und freigegebene Speicherobjekte erstellen können. Malware könnte diese Freigabe zum Beispiel ausnutzen, um ein freigegebenes Speicherobjekt, das von einer Anwendung mit erweiterter Berechtigung verwendet wird, zu kapern, um die Anwendung und dadurch das System zu beeinträchtigen.

Wie auch Windows Integrity Mechanism ist ihre Wirksamkeit als Barriere durch die bereits erwähnten Erweiterungsprobleme eingeschränkt, weitere Beschränkungen entstehen durch Anwendungskompatibilität. UIPI verhindert nicht, dass Standardbenutzeranwendungen etwas auf dem Desktop ausgeben. Dies könnte Malware ausnutzen, um Benutzer dazu zu verführen, mit Anwendungen mit erweiterter Berechtigung zu kommunizieren, sodass Malware Administratorrechte erteilt werden. Windows Integrity Mechanism wirkt auch nicht über das Netzwerk. Eine Standardbenutzeranwendung, die in einem PA-Konto ausgeführt wird, hat Zugriff auf Systemressourcen auf einem Remotesystem, auf dem dieses PA-Konto Administratorrechte hat. Wenn diese Einschränkungen aufgehoben werden sollen, hat dies erhebliche Auswirkungen auf die Anwendungskompatibilität. Das heißt, wir suchen ständig nach Möglichkeiten, um die Systemsicherheit zu verbessern, indem wir zum Beispiel Internet Explorer im geschützten Modus verbessern, während wir gleichzeitig Probleme bei der Anwendungskompatibilität lösen und mit Softwareentwicklern zusammenarbeiten.

Wie viel Malware-Schutz erhalten Sie also, wenn Sie eine Anwendung in einem Windows Vista-PA-Konto mit aktivierter UAC ausführen? Denken Sie in diesem Zusammenhang immer daran, dass Malware erst einmal auf das System gelangen und mit der Ausführung beginnen muss. Windows hat viele weit reichende Verteidigungsfeatures, einschließlich Datenausführungsverhinderung (Data Execution Prevention, DEP), Address Space Load Randomization (ASLR; Adressraumrandomisierung beim Laden), Internet Explorer im geschützten Modus, SmartScreen-Filter in Internet Explorer 8 sowie Windows Defender, die dazu beitragen, zu verhindern, dass Malware in das System gelangt und ausgeführt wird.

Wenn es Malware irgendwie schafft, in ein System zu gelangen, wird sie meistens nicht richtig funktionieren, weil Malwareautoren (genau wie normale Entwickler) angenommen haben, dass Benutzer Anwendungen mit Administratorrechten ausführen. Allein dies könnte als Sicherheitsvorteil angesehen werden. Malware, die in ein System gelangt ist und so konzipiert ist, dass sie Schwachstellen ausnutzt, könnte jedoch in der Lage sein, sich Administratorrechte zu verschaffen, sobald der Benutzer zum ersten Mal die Berechtigung erweitert. Malware muss jedoch nicht einmal auf eine „echte“ Berechtigungserweiterung warten, weil sie eine Erweiterung auslösen kann, die selbst den sicherheitsbewusstesten Benutzer überlisten würde. In meinen Präsentationen UAC-Interna und Windows-Sicherheitsgrenzen habe ich öffentlich gezeigt, wie Malware den Prozess zur Berechtigungserweiterung kapern kann (die Demo befindet sich im Gespräch über Sicherheitsgrenzen in Minute 1:03). Bedenken Sie jedoch, dass einmal ausgeführte Malware das Meiste von dem, wozu sie gedacht ist, bereits mit Standardbenutzerrechten tun kann. Dazu zählen die Selbstkonfiguration, damit sie bei jeder Anmeldung des Benutzers ausgeführt wird, Diebstahl oder Löschung sämtlicher Benutzerdaten oder Aufnahme in ein Botnet.

Was ist anders in Windows 7?

Ich habe bereits einige der Vorgänge in Windows 7 erwähnt, die ab sofort von Standardbenutzern durchgeführt werden können. Wie aus dem E7-Weblogbeitrag zu UAC hervorgeht, haben wir allerdings auch festgestellt, dass wir die Windows-Erfahrung verbessern können, ohne die Ziele von UAC zu beeinträchtigen. Viele Benutzer haben sich darüber beschwert, dass Windows Vista bei der Durchführung gängiger Systemverwaltungsvorgänge häufig nach Administratorberechtigungen fragt. So liegt es auch in unserem Interesse, zur Zufriedenheit unserer Kunden dafür zu sorgen, dass Windows in Standardbenutzerumgebungen zuverlässig funktioniert. Eingabeaufforderungen zur Berechtigungserweiterung leisten hierzu allerdings keinen Beitrag, zwingen jedoch Benutzer zu einem zweiten Klick in einem Dialogfeld, das von der Mehrzahl der Benutzer nicht einmal gelesen wird. In Windows 7 sollten diese Eingabeaufforderungen daher minimiert werden und Administratoren die Möglichkeit bieten, selbst über diese Funktionalität zu bestimmen.

Dazu haben wir das System so umgestaltet, dass ein Benutzer mit Standardberechtigungen mehr Aufgaben ausführen kann. Darüber hinaus haben wir die Anzahl der Eingabeaufforderungen in verschiedenen Szenarien mit mehreren Eingabeaufforderungen reduziert (z. B. beim Aktivieren von ActiveX-Steuerelementen in IE). Mit Windows 7 werden außerdem zwei neue UAC-Betriebsmodi eingeführt, die Benutzer über ein neues UAC-Konfigurationsdialogfeld auswählen können (siehe Abbildung 3). Zum Aufrufen des Dialogfelds öffnen Sie die Systemsteuerung, klicken auf Benutzerkonten und anschließend auf Einstellungen der Benutzerkontensteuerung ändern. (Alternativ können Sie das Dialogfeld auch über Action Center aufrufen, oder indem Sie in einer Eingabeaufforderung zur Berechtigungserweiterung auf den Link zum Ändern bei der Anzeige von Benachrichtigungen klicken.)

Abbildung 3 Über ein neues UAC-Konfigurationsdialogfeld können zwei neue UAC-Betriebsmodi ausgewählt werden.

Die in Abbildung 3 gezeigte Standardeinstellung ist eine der neuen Stufen. Im Gegensatz zur Option Immer benachrichtigen am oberen Ende des Schiebereglers, die dem Standardmodus in Windows Vista entspricht, wird für Windows 7-Benutzer nur dann eine Eingabeaufforderung angezeigt, wenn eine Berechtigungserweiterung für eine Windows-fremde ausführbare Datei erforderlich ist. Das Verhalten bei Windows-fremden Berechtigungserweiterungen entspricht dem von Windows Vista.

Die nächste Schiebereglerposition ist die zweite neue Einstellung mit derselben Bezeichnung und einem Zusatz („Desktop nicht abblenden“). Der einzige Unterschied zwischen dieser Option und dem Standardmodus ist, dass die Eingabeaufforderung auf dem Desktop des Benutzers und nicht auf dem sicheren Desktop erfolgt. Der Vorteil ist, dass der Benutzer den Desktop verwenden kann, während eine Eingabeaufforderung aktiv ist. Wie jedoch bereits erwähnt, besteht das Risiko, dass Eingabehilfesoftware von Drittanbietern möglicherweise in Verbindung mit der Eingabeaufforderung nicht wie gewünscht funktioniert.

Mit der untersten Schiebereglerposition werden alle UAC-Funktionen deaktiviert, sodass alle Softwareprogramm in einem PA-Konto mit vollen Administratorberechtigungen ausgeführt werden. Dateisystem- und Registrierungsvirtualisierung sowie der geschützte Modus von IE sind dabei deaktiviert. Bei dieser Einstellung werden zwar keine Eingabeaufforderungen angezeigt, der Verzicht auf den geschützten Modus von IE ist jedoch ein erheblicher Nachteil.

Automatische Berechtigungserweiterung

Der Grund dafür, dass die Berechtigungserweiterung der (meisten) ausführbaren Windows-Dateien durch die beiden mittleren Einstellungen nicht zu einer Eingabeaufforderung führt, ist, dass die Berechtigungen für ausführbare Windows-Dateien vom System automatisch erweitert werden. Dabei stellt sich zunächst die Frage, was Windows in diesem Kontext als ausführbare Windows-Datei betrachtet. Die Antwort ist von verschiedenen Faktoren abhängig, zwei Aspekte sind jedoch obligatorisch: Die Datei muss vom Windows-Herausgeber, d. h. dem Zertifikat zum Signieren des gesamten Windows-Codes, digital signiert sein (eine Signierung von Microsoft ist nicht ausreichend, d. h. Microsoft-Software, die nicht mit Windows ausgeliefert wird, ist nicht enthalten); und sie muss sich in einem der wenigen „sicheren“ Verzeichnisse befinden. Bei einem sicheren Verzeichnis handelt es sich um ein Verzeichnis, das von Standardbenutzern nicht geändert werden kann, d. h. %SystemRoot%\System32 (z. B. \Windows\System32) und fast alle Unterverzeichnisse, %SystemRoot%\Ehome sowie einige wenige Verzeichnisse unter %ProgramFiles%, darunter Windows Defender und Windows Journal.

Je nachdem, ob es sich bei der ausführbaren Datei um eine herkömmliche Datei mit der Erweiterung .exe, Mmc.exe oder ein COM-Objekt handelt, gelten zusätzliche Regeln für die automatische Berechtigungserweiterung. Die Berechtigungen für ausführbare Windows-Dateien (wie oben definiert) vom Typ .exe werden automatisch erweitert, wenn im Manifest die Eigenschaft autoElevate angegeben ist. Dort wird für Anwendungen UAC gegenüber auch angegeben, dass Administratorberechtigungen benötigt werden. Abbildung 4 zeigt das Abrufen des Manifests für den Task Manager (Taskmgr.exe) mit dem Befehl „sigcheck –m %systemroot%\system32\taskmgr.exe“ des Sysinternals-Dienstprogramms Sigcheck. Hier wird ersichtlich, dass die automatische Berechtigungserweiterung für den Task Manager aktiviert ist.

Abbildung 4 Die Eigenschaft autoElevate

Eine einfache Methode zum Ermitteln ausführbarer Dateien mit automatischer Berechtigungserweiterung in einer Verzeichnisstruktur ist die Verwendung des Sysinternals-Dienstprogramms Strings mit einem solchen Befehl:

strings –s *.exe | findstr /i autoelevate

Außerdem gibt es eine feste Liste ausführbarer Windows-Dateien, für die eine automatische Berechtigungserweiterung erfolgt. Diese ausführbaren Windows-Dateien werden unabhängig von Windows 7 verkauft und müssen daher auch Abwärtskompatibilität mit älteren Systemen bieten, bei denen das Vorhandensein der Eigenschaft autoexecute (AutoAusführen) zu Fehlern führen würde. Die Liste umfasst Migwiz.exe, den Migrations-Assistenten, Pkgmgr.exe, den Paket-Manager, und Spinstall.exe, das Service Pack-Installationsprogramm.

Für Microsoft Management Console, Mmc.exe, gilt eine Sonderbehandlung, da sie zahlreiche Systemverwaltungs-Snap-Ins beinhaltet, die als DLLs implementiert sind. Mmc.exe wird mit einer Befehlszeile gestartet, in der eine .MSC-Datei angegeben ist, welche die von MMC zu ladenden Snap-Ins enthält. Wenn Mmc.exe Administratorberechtigungen fordert, wie z. B. beim Starten über ein PA-Konto, wird geprüft, ob Mmc.exe eine ausführbare Windows-Datei ist. Anschließend wird die .MSC-Datei überprüft. Für die automatische Berechtigungserweiterung muss die .MSC-Datei die Kriterien für ausführbare Windows-Dateien erfüllen (von Windows signiert, an einem sicheren Speicherort gespeichert) und auf einer internen Liste von .MSC-Dateien für die automatische Berechtigungserweiterung aufgeführt sein. Diese Liste umfasst im Prinzip alle im Lieferumfang von Windows enthaltenen .MSC-Dateien.

Für COM-Objekte kann der Bedarf nach Administratorberechtigungen durch einen Registrierungswert im Registrierungsschlüssel angegeben werden, indem ein Unterschlüssel „Elevation“ mit einem Wert „Enabled“ erstellt wird, der „1“ lautet. Abbildung 5 zeigt den Registrierungsschlüssel für die Shell-Befehle „Kopieren/Verschieben/Umbenennen/Löschen/Verknüpfung erstellen“, die im Explorer verwendet werden, wenn ein Benutzer einen Dateisystemvorgang an einem Speicherort ausführt, für den er nicht über die erforderliche Berechtigung verfügt.

Abbildung 5 Shell-Registrierungsschlüssel

Damit die automatische Berechtigungserweiterung erfolgt, muss es sich bei dem COM-Objekt ebenfalls um eine ausführbare Windows-Datei handeln, die von einer ausführbaren Windows-Datei instanziiert wurde. (Die instanziierende ausführbare Datei muss jedoch nicht zur automatischen Berechtigungserweiterung markiert sein.) Wenn Sie beispielsweise über ein PA-Konto mit dem Explorer im Verzeichnis %ProgramFiles% ein Verzeichnis erstellen, erfolgt eine automatische Berechtigungserweiterung, da für das COM-Objekt eine Berechtigungserweiterung erforderlich ist, es sich bei der Objekt-DLL um eine ausführbare Windows-Datei handelt und der Explorer eine ausführbare Windows-Datei ist.

Automatische Berechtigungserweiterung und Ziele der Benutzerkontensteuerung

Was steckt also hinter all diesen Sonderregeln zur automatischen Berechtigungserweiterung? Die Entscheidung, wann eine automatische Berechtigungserweiterung erfolgen sollte, basiert auf der Frage „Kann ein Anwendungsentwickler seine Anwendung durch Nutzung der automatischen Berechtigungserweiterung unbeabsichtigt oder der Einfachheit halber mit Administratorberechtigungen ausführen lassen?“. Da Cmd.exe zur Ausführung von Stapelverarbeitungsskripten über Befehlszeilenargumente verwendet werden kann und für durchschnittliche Benutzer keine Notwendigkeit zum Ausführen von Eingabeaufforderungen mit Berechtigungserweiterung besteht (da viele nicht einmal wissen, was eine Eingabeaufforderung ist), erfolgte keine Aufnahme der automatischen Berechtigungserweiterung in das Manifest. Analog dazu erfolgt für Rundll32.exe, die ausführbare Datei, die Systemsteuerungs-Plug-Ins beinhaltet, in der letzten Version von Windows 7 keine automatische Berechtigungserweiterung, da eine solche Erweiterung für gängige Verwaltungsaufgaben nicht erforderlich ist. Erfolgt jedoch eine automatische Berechtigungserweiterung, kann die Möglichkeit zur Verwendung beliebiger DLLs über die Befehlszeile dazu führen, dass ein Entwickler unwissentlich Administratorberechtigungen anfordert.

Seit Veröffentlichung der Windows Vista-Betaversion haben viele Endbenutzer um eine Möglichkeit gebeten, unter Windows beliebige Anwendungen zur Liste für die automatische Berechtigungserweiterung hinzuzufügen. Der am häufigsten genannte Grund ist, dass sie bei einigen oft verwendete Drittanbieteranwendungen ständig dazu gezwungen sind, sich für Routineaufgaben durch eine Eingabeaufforderung zur Berechtigungserweiterung zu klicken. Windows 7 bietet, genau wie Windows Vista, keine solche Funktion. Wir verstehen die Verärgerung, und es ist durchaus möglich, dass es einen legitimen Grund dafür gibt, dass diese Anwendungen ohne Administratorrechte nicht ausgeführt werden können. Es besteht jedoch ein zu hohes Risiko, dass Entwickler darauf verzichten könnten, ihren Code so zu ändern, dass auch eine Verwendung mit Standardbenutzerberechtigungen möglich ist. Selbst wenn die Liste der Anwendungen, für die eine automatische Berechtigungserweiterung zulässig ist, nur Administratoren zugänglich wäre, könnten Anwender einfach das Anwendungsinstallationsprogramm ändern, für das eine einmalige Berechtigungserweiterung erforderlich ist, damit ihre Anwendung in die Liste aufgenommen wird. Stattdessen haben wir uns entschlossen, in Schulungen und enge Zusammenarbeit mit Anwendungsentwicklern zu investieren, um dafür zu sorgen, dass ihre Programme auch von Standardbenutzern problemlos verwendet werden können.

Vielen Benutzern ist aufgefallen, dass für Drittanbietersoftware, die mit Standardbenutzerberechtigungen über ein PA-Konto ausgeführt wird, die Möglichkeit besteht, die automatische Berechtigungserweiterung zu nutzen, um Administratorberechtigungen zu erhalten. So kann beispielsweise mit der WriteProcessMemory-API Code in den Explorer eingeschleust und mithilfe der CreateRemoteThread-API ausgeführt werden. Diese Technik wird als DLL Injection bezeichnet. Da der Code im Explorer, einer ausführbaren Windows-Datei, ausgeführt wird, können die COM-Objekte mit automatischer Berechtigungserweiterung, wie z. B. die Befehle „Kopieren/Verschieben/Umbenennen/Löschen/Verknüpfung erstellen“ dazu genutzt werden, Systemregistrierungsschlüssel oder Verzeichnisse zu ändern und der Software Administratorberechtigungen zu verleihen. Obwohl dies natürlich technisch möglich ist, müssten diese Schritte mit Vorsatz durchgeführt werden. Darüber hinaus sind sie nicht einfach und aus diesem Grund keine Methode, von der seriöse Entwickler unserer Ansicht nach Gebrauch machen würden, um zu vermeiden, dass sie ihre Software reparieren müssten, damit sie mit Standardbenutzerberechtigungen ausgeführt werden kann. Wir raten Anwendungsentwicklern sogar dringend davon ab, Bezug auf das Berechtigungserweiterungsverhalten des Systems zu nehmen. Des Weiteren sollten Anwendungsentwickler ihre Software im Standardbenutzermodus testen.

Die Schlussfolgerung ist, dass unter Anwendung der genannten Technik Administratorberechtigungen mithilfe von Malware erworben werden könnten. Auch diese Annahme ist zutreffend, wie jedoch bereits an anderer Stelle angemerkt, könnte Malware das System auch durch Eingabeaufforderungen zur Berechtigungserweiterung beeinträchtigen. Aus der Sicht von Malware ist der Standardmodus von Windows 7 nicht sicherer als der Modus <strong>Immer benachrichtigen</strong> („Vista-Modus“), und Malwareprogramme, die Administratorberechtigungen annehmen, würden bei Ausführung im Standardmodus von Windows 7 weiterhin wirken.

Schlussbemerkung

Zusammenfassend gesagt ist UAC ein Technologiepaket mit einem übergeordneten Ziel: Benutzern die Ausführung von Programmen als Standardbenutzer zu ermöglichen. Die kombinierten Änderungen an Windows, die es Standardbenutzern gestatten, mehr Vorgänge auszuführen, für die bislang Administratorberechtigungen, Dateisystem- und Registrierungsvirtualisierung und Eingabeaufforderungen erforderlich waren, tragen gemeinsam dazu bei, dieses Ziel zu erreichen. Als Fazit lässt sich sagen, dass durch den UAC-Standardmodus von Windows 7 die Benutzererfahrung für PA-Benutzer verbessert wird, da weniger Eingabeaufforderungen angezeigt werden und Benutzer selbst steuern können, welche Software zu Systemänderungen berechtigt sein soll. Gleichzeitig wird dennoch das UAC-Ziel erreicht, mehr Software ohne Administratorberechtigungen ausführen zu können und die Welt der Softwareentwicklung dahingehend zu verändern, dass neu entwickelte Software mit Standardbenutzerberechtigungen verwendbar ist.

Mark Russinovich ist Technical Fellow in der Platform and Services Division bei Microsoft.