Windows: UAC-Programmverhalten abhängig vom Namen

[English]Heute noch ein Blog-Beitrag aus der Mottenkiste 'Windows skurril'. Ist euch bekannt, dass der Name eines Programmes dessen Verhalten im Punkto Aufruf der Benutzerkontensteuerung beeinflussen kann? Ich wollte es kaum glauben – aber die Microsoft-Entwickler haben da in den Eingeweiden von Windows einige Balkone 'gestrickt' (neudeutsch als Heuristik bezeichnet), die manches zum Lotteriespiel macht. Ist zwar dokumentiert, aber imho wenig bekannt.

Eine Leseranfrage zu einem seltsamen Verhalten

Vor einigen Tagen hat mich Blog-Leser Andreas T. per Mail kontaktiert, um mir von einem seltsamen Verhalten in Windows zu berichten. Er hatte eine Programmdatei umbenannt und plötzlich startete diese mit einer Abfrage der Benutzerkontensteuerung, um administrative Berechtigungen zu erlangen. Andreas schrieb mir:

ich habe aktuell eine Frage zum Thema "Windows", bei der ich aus dem Verhalten des Systems nicht schlau werde:

Ich habe das Spiel Quake2 installiert, zu dem die ausführbare Datei "quake2.exe" gehört.

Wenn ich die Datei im Explorer mit Rechtsklick kopiere als "quake2 – Kopie.exe", wird die Datei ganz normal dargestellt und ist auch ausführbar, ohne daß die Benutzerkontensteuerung aktiviert wird.

Benenne ich die Datei in "quake2patched.exe" um, wird die Datei mit einem Schild (siehe Screenshot) im Explorer dargestellt und ich erhalte beim Start eine Anfrage der Benutzerkontensteuerung.

Der obige Screenshot untermauert das Ganze. Andreas hat dann geprüft, ob sich beim Kopieren was geändert hat, aber ohne Erfolg. Dazu schreibt er:

Die drei Dateien sind identisch.

F:\Quake II>fc /b quake2.exe quake2patched.exe
Vergleichen der Dateien quake2.exe und QUAKE2PATCHED.EXE
FC: Keine Unterschiede gefunden

Benenne ich die "quake2patched.exe" um in z.B. "quake2test.exe" verschwindet das Schild-Symbol.

Haben Sie eine logische Erklärung? Es scheint am Dateinamen zu hängen – aber warum?

Ich hatte ad hoc keine logische Erklärung für diesen Effekt, konnte aber auch nicht reagieren, da ich unterwegs war. Ein Kurztest, den ich mit dem Windows-Editor Notepad durchführte, ergab aber ein merkwürdiges Bild. Wenn ich notepad.exe mit administrativen Berechtigungen kopiere und dann in notepadpatched.exe umbenenne, startet der Editor nicht mehr.

Erklärung: Benutzerkontensteuerung in Vista

Das Ganze hat seine Ursprünge wohl in Windows Vista, als Microsofts Programmierer die Benutzerkontensteuerung einführten. Programme, die administrative Berechtigungen erfordern, müssen diese über die Benutzerkontensteuerung anfordern. Eigentlich eine gute Sache.

Geregelt wird die Anforderung über ein Manifest, welches separat beiliegen kann, meist aber in der .exe-Datei enthalten ist. Dieses legt fest, ob das Programm administrative Berechtigungen braucht. Trifft dies zu, wird das Icon der Programmdatei mit dem stilisierte Schild versehen. Beim Aufruf erscheint dann auch die Benutzerkontensteuerungsabfrage.

Der Benutzer kann zudem eine Verknüpfung auf eine Programmdatei anlegen und dieser das Attribut Als Administrator ausführen zuweisen. Und es gibt die Möglichkeit, den Kontextmenübefehl  Als Administrator ausführen zum Programmstart zu verwenden. So weit so klar und alles in Ordnung.

Heuristik, oder Balkon-Programmierung in Windows

Aber es gab ja jede Menge Alt-Programme die von diesem Mechanismus nichts wussten. Also finden die Microsoft-Entwickler mit 'Balkonprogrammierung' an – sprich: Verwendung von trickreichen Ansätzen, um zu erkennen, dass ein Programm administrative Berechtigungen braucht. Und dann kommt so ein Mist wie oben erwähnt bei heraus.

Wird beispielsweise der Registrierungseditor Regedit.exe unter einem Standard-Benutzerkonto aufgerufen, startet er mit normalen Berechtigungen. Unter einem Administratorkonto wird dagegen die Benutzerkontensteuerung aktiv und ermöglicht es, den Registrierungseditor mit administrativen Rechten auszuführen. Der Start mit Als Administrator ausführen ist nicht mehr erforderlich.

Beim explorer.exe funktioniert das aber nicht, weil Windows intern die Ausführung mit administrativen Berechtigungen blockt – denn der Explorer ist ja auch für die Windows-Shell (Desktop etc.) zuständig. Ich hatte dies im Blog-Beitrag Explorer als Administrator ausführen mal thematisiert.

Installer Detection: Die schmutzigen Seiten des Ganzen

Geht man im Internet mit den richtigen Begriffen auf die Suche, stößt man vermutlich auf diesen stackoverflow.com-Thread. Dort erklärt jemand ein paar Winkelzüge, die bei 32-Bit-Programmdateien von Windows auftreten können. Microsoft hat dies 2006 für Windows Vista in diesem länglichen Dokument (Understanding and Configuring User Account Control in Windows Vista) beschrieben. Im Abschnitt Installer Detection legt man einige interne Tricks offen.

Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:

• Filename includes keywords like "install," "setup," "update," etc.
• Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
• Keywords in the side-by-side manifest embedded in the executable.
• Keywords in specific StringTable entries linked in the executable.
• Key attributes in the RC data linked in the executable.
• Targeted sequences of bytes within the executable.

Genau dort findet sich die Information, dass die Schlüsselwörter install, setup, update etc. im Programmnamen dieses Verhalten hervorrufen. Besonders spannend finde ich das "etc." in der Beschreibung, denn das lässt Raum für viele Möglichkeiten.

Auch in der Registrierung lässt sich die Ausführung einer Anwendung per Benutzerkontensteuerung konfigurieren (siehe hier).

Bevor ich antworten konnte, schickte mir Andreas bereits eine zweite Mail. Dort schrieb er: kaum hat man die Frage abgeschickt, wird man beim MSDN doch noch fündig. Es ist tatsächlich der Dateiname, ich habe gerade einen entsprechenden Blog-Artikel verfasst. Er bezieht sich dabei auf den MSDN-Blog-Beitrag UAC: Five most common Install failure Scenarios and workarounds (Link gelöscht) von 2007, der das Ganze nochmals kompakter aufbereitet hat.

Meine abschließenden 2 Cents

Mit der Benutzerkontensteuerung bzw. der daran hängenden Implementierung hat Microsoft ein Monster geschaffen. Quasi ein Jahr nach dem ersten Artikel aus 2006 sah man sich schon gezwungen, einen erklärenden Artikel nachzuschieben. Das Verhalten von Programmen ist also nicht mehr deterministisch, sondern wird von einer Heuristik mit beeinflusst.

Solche Balkone sind oft der Grund, wenn irgend wann etwas mit Anwendungen gravierend in die Hose geht. Möglicherweise sind auch die Fälle, wo Anwender plötzlich damit konfrontiert sind, dass alle Programme nur noch mit Administratorrechten starten, auf solche Heuristiken (mit Registry-Einträgen) zurückzuführen.

Abschließender Gedanke: Vermutlich braucht Schadsoftware das nicht, weil sie mit Manifesten in den .exe-Dateien arbeiten kann. Aber es wären Szenarien denkbar, wo die Malware die Programmdateien nach einer bestimmten Zeit einfach umbenennt und so den Aufruf der UAC per Heuristik erzwingt, um den Anwender auszutricksen. Eigentlich könnte die Benutzerkontensteuerung (UAC) eine gute Sache sein. Aber mit so etwas macht man das Ganze schlicht kaputt. Oder wie seht ihr das so? Und war euch das bekannt?