Zu historischen DOS Zeiten war die Länge von Dateinamen auf acht Zeichen plus drei Zeichen Erweiterung beschränkt. Auch waren keine Leerzeichen im Dateinamen erlaubt. Manche Programmierer haben es bis heute nicht verinnerlicht, dass seit Windows 95 bzw. NT4 diese Beschränkung nicht mehr gilt.
Heutzutage verwendet Windows sogar standardmäßig in diversen Pfadnamen Leerzeichen, z.B. heißt der Programme-Ordner im Dateisystem tatsächlich “Program Files”. Technisch ist dies an sich kein Problem. Es ergibt sich daraus aber eine kleine Falle.
Ebenfalls zu DOS Zeiten leitete ein Leerzeichen nach einem Dateinamen zu eventuell anzugebenden Parametern über. Das System erwartet somit eigentlich nicht, dass nach einem Leerzeichen der Name eines Ordners oder Programmes weitergeht. Um dem System dies zu sagen, ist der Pfad in Anführungszeichen einzuschließen.
“C:\Program Files\7-zip\7z.exe”
beispielsweise startet als Befehl die Kommandozeilenversion des Packers 7-zip.
C:\Program Files\7-zip\7z.exe
hingegen führt zur Fehlermeldung
Der Befehl „c:\Program“ ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Es wird also statt des Ordners “Program Files” ein Programm namens “Program” gesucht.
Rufe ich an der Kommandozeile aus einem Ordner unterhalb von “Program Files” ein Programm auf und nutze dafür die automatische Vervollständigung, baut Windows automatisch den gesamten Pfad in Anführungszeichen und ruft das Programm richtig auf.
Stelle ich jetzt im Laufwerk C:\ eine Datei namens Program.exe bereit, würde statt meines Packers 7-Zip dieses Programm aufgerufen. Nicht unbedingt das, was ich gerne möchte. Nun ist C:\ nicht von jedem Nutzer beschreibbar. Um dort hin eine Program.exe zu schreiben braucht man zumindest Adminrechte.
Allerdings taucht das Phänomen natürlich auf allen Laufwerken auf. Wer auf D:\ ein Spiel in einen Ordner “Mein Spiel” installieren würde und dieses dann mit einem Befehl ohne Anführungszeichen starten wollen würde, würde eine Mein.exe in D:\ starten – und dort könnte sie jeder Benutzer deponieren.
Nun ruft man doch eher selten Programme per Kommandozeile auf und wenn, ergänzt diese meist ja automatisch die Pfade. Allerdings gibt es eine andere Stelle, an der die Sache zum Problem werden kann: die Registry.
Windows führt viele Dienste standardmäßig mit den Rechten “Lokales System” aus. Sie laufen also mit den Berechtigungen des Systems selber – und haben damit grundsätzlich mehr Berechtigungen als z.B. ein Administrator.
So sieht das in der Liste der Dienste zum Beispiel aus:
Die Dienste finden sich in der Registry im Zweig HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services jeweils mit einem eigenen Unterschlüssel, in dem definiert wird, ob der Dienst automatisch gestartet wird, mit welchem Benutzer er sich anmelden soll und natürlich, welches ausführbare Programm denn gestartet werden soll.
Das kann dann zum Beispiel so aussehen:
In diesem Fall hat ASUS alles richtig gemacht. Der ASUS Dienst “asComSvc” ist zwar unterhalb von “Program Files” installiert, der Pfad wird aber sauber mit Anführungszeichen versehen. Windows startet hier also beim Laden auf jeden Fall die richtige Programmdatei.
Oft genug wird es aber falsch gemacht und der ImagePath verweist ohne Anführungszeichen auf ein Programm. Und damit wird, wie im Beispiel meiner Kommandozeile oben, dann ggfs. ein ganz anderes Programm gestartet, nämlich C:\Program.exe, so jemand diese Datei dort platziert hat.
Kopiere ich also jetzt eine notepad.exe als program.exe auf C:\ und starte das System neu, wird meine notepad.exe mit Systemrechten ausgeführt. Und das ist dann eine Sicherheitslücke, denn damit habe ich es geschafft, von Adminrechten zu Systemrechten zu kommen, einfach nur durch Kopieren einer Datei. So etwas ist eine – noch vergleichsweise harmlose – “Privilege Escalation” Lücke.
Es gibt allerdings auch Situationen, in denen die Sache weniger harmlos wird. Denn nicht immer betrifft es das Verzeichnis “Program Files” selber. Der Hersteller einer Software könnte ja auch beispielsweise “C:\Program Files\Hersteller\Meine Software\dienst.exe“ ausführen wollen. Und es gibt sogar Hersteller, die es in so einem Beispiel schaffen, unterhalb des “Hersteller” Ordners die Berechtigungen so zu setzen, dass Benutzer Schreibzugriff bekommen.
Damit hätte man dann ein massives Loch gerissen, denn dann würde ein normaler Benutzer ohne Adminrechte mit einem einfachen Kopiervorgang und einem Neustart volle Systemrechte erlangen können.
Da man solche – in diesem Fall konstruierten – Situationen nicht wirklich abschätzen kann, ist es schlichtweg notwendig, beim Laden von Diensten grundsätzlich diese auch in Anführungszeichen zu setzen.
Eher durch Zufall bin ich Ende 2018 darauf gestoßen, dass der Treiber für das Synaptics Touchpad meines Lenovo Notebooks genau für solch ein Problem anfällig ist. Das Problem wurde an Lenovo gemeldet und entsprechend von Lenovo bzw. Synaptics beseitigt. Auch wenn es in dem Fall nur die Variante war, bei dem man sich vom Administrator zu Systemrechten verhelfen konnte.
https://support.lenovo.com/de/de/product_security/len-24573
Von der Meldung bis zum Advisory bei Lenovo vergingen gute sechs Wochen. Und die aktuelle Treiberversion verwendet dann brav die Anführungszeichen in der Registry, die solch einen Unterschied machen können.
Selber scannen kann man so etwas übrigens schon über die für private Nutzung kostenlosen Home Version des Sicherheitsscanners Nessus. Mit der kommerziellen Pro Version natürlich ebenfalls…
https://www.tenable.com/products/nessus-home
Nessus war es dann auch, der mich vor längerem mal drauf hinwies, dass eine “Sicherheitssoftware” in ihrem Installationspfad die Berechtigungen auf “Jeder, Vollzugriff” setzte und in selbigem Pfad auch die Dateien der Systemdienste des Programmes zu finden waren. Aber das ist dann eine andere Geschichte.