PSA: Classic Shell heißt jetzt Open Shell Menu – und eine Warnung

Neue Informationen für Nutzer und Interessierte des Windows-Tools Classic Shell: Das Nachfolgeprojekt wurde bereits wieder umbenannt und heißt jetzt Open Shell Menu. Hier ein paar Informationen und ein Hinweis, warum ich (derzeit) sagen würde ‚Vorsicht‘.

Es gibt Software, die sich durch Umbenennung im Fokus der Aufmerksamkeit hält. In diese Kategorie würde ich das Classic Shell Projekt einordnen, denn dieses Projekt wurde erneut umbenannt.

Ein wenig Hintergrund

Der Entwickler der Classic Shell, Ivo Beltchev, hat die Entwicklung der Software schon vor einiger Zeit eingestellt. Aber er hat den Quellcode der Community zur weiteren Pflege zur Verfügung gestellt. Darüber habe ich in meinem deutschen Blog berichtet.

Aber was für meinen Geschmack nicht so schön ist: Im Moment produziert das Projekt aufgrund mehrfacher Umbenennungen nur noch Schlagzeilen. Für kurze Zeit hieß das Tool Classic Start. Dann beschloss die Community Ende Juli 2018, es in NeoClassic-UI/Menu umzubenennen. Vielleicht gibt es dafür gute Gründe, ich weiß es nicht, sie wurden nie genannt.

Der nächste neue Name …

Und nun wurde das Projekt in Open-Shell-Menu umbenannt. Die aktuelle Installationsdatei heißt nun OpenShellSetup_4_4_126.exe, aber die Funktionalität hat sich wohl nicht geändert. Das Projekt ist auf GitHub verfügbar, aber noch nicht alle Links funktionieren. Der aktuelle Nightly Build ist hier verfügbar, der nach 6 Monaten ausläuft.

Die dunkle Seite dieses Projekts: Sicherheit

Neben dem ‚ein Sack Reis ist in China umgefallen, bitte weiterfahren, es gibt nichts zu sehen‘, möchte ich darauf hinweisen, dass man die Finger von diesem Tool lassen sollte (zumindest, bis die Entwickler ein paar grundlegende Dinge behoben haben). Warum diese Warnung?

Ich stehe seit einiger Zeit mit dem White Hat Hacker Stefan Kanthak (siehe) in Kontakt (Microsoft nimmt ihn in die Top 100 MSRC 2017 auf und auch in andere Listen, wie z.B. Top 100 Finders in 2015). Forscher im Jahr 2015 (siehe).

Stefan Kanthak hat einen deutschen Kommentar gepostet, in dem er einige kritische Punkte darlegt. Hier ein kurzer Auszug:

• Der Einfachheit halber liefern die Entwickler einen .exe-Installer (statt einer .msi-Datei). Dieser Installer muss mit administrativen Rechten ausgeführt werden, um die Software zu installieren. Das Installationsprogramm entpackt die erforderlichen Dateien in ein (ungeschütztes) TEMP-Verzeichnis. Problem: Befindet sich Malware auf dem System, die derzeit nur mit den Rechten eines eingeschränkten Benutzerkontos läuft, wird die Falle aktiviert.
• Diese Malware kann den Entpackungsvorgang bemerken (es gibt Windows-APIs, die dies melden und eine ‚Hook-Funktion‘ der Malware aufrufen können). Dann genügt es, eine DLL-Datei mit einem bestimmten Namen in den TEMP-Ordner zu kopieren (da dieser ungeschützt ist, ist dies mit eingeschränkten Benutzerrechten möglich).
• Während des Installationsprozesses versucht der Installer, die vermeintliche Windows-DLL zu laden, greift aber aufgrund der Windows-Eigenschaften auf die von der Malware platzierte DLL zu. Und prompt erhält die Malware über die DLL administrative Rechte.

Dies ist seit langem als DLL-Suchauftrags-Hijacking bekannt, ein potentielles Sicherheitsrisiko und sollte unbedingt vermieden werden. Stefan Kanthak hat in seinem deutschen Kommentar einige Links und weitere Details gepostet. Als Schlussfolgerung: Solange das Projekt diese Probleme nicht angegangen ist, würde ich den Einsatz solcher Software vermeiden/vorsichtig sein.

Nachtrag: An dieser Stelle muss ich einen kleinen Rückzieher machen. Ich habe mir das Installationsprogramm (unter Windows 7) angeschaut. Interessante Beobachtung: Der deutsche Leser Martin Feuerstein hatte in einem Kommentar darauf hingewiesen, dass der .exe-Installer einen Schalter zum Entpacken der .msi-Installer hat – kann mit /? angezeigt werden. So kann man die .msi entpacken und die 32-/64-Bit-Version per .msi-Installer installieren.

Eine weitere Beobachtung: Offenbar läuft der .exe-Installer beim Entpacken nur mit Standardbenutzerrechten, entpackt die .msi-Dateien und ruft die entsprechende auf. Das .msi-Installationsprogramm aktiviert die UAC-Eingabeaufforderung aufgrund von Einstellungen in seinem Manifest und installiert das Tool. Damit ist der oben beschriebene Angriffsvektor nach meinem derzeitigen Kenntnisstand beseitigt (ob die richtige msi die UAC aufruft, kann in der UAC-Eingabeaufforderung überprüft werden). Wenn es neue Erkenntnisse gibt, werde ich sie hinzufügen.

Nachtrag 2: Laut Stefan Kanthak hat das Installationsprogramm ClassicStartSetup_4_4_109.exe folgende Abhängigkeiten – zu erhalten mit:

LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe

COMCTL32.dll
VERSION.dll
KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll

Und die oben genannten DLLs hängen von GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll und
SHLWAPI.dll ab. Seit Windows Vista ist VERSION.dll keine „bekannte DLL“ mehr und jede Datei mit diesem Namen wird aus dem Verzeichnis der Anwendung geladen, sofern vorhanden. Dasselbe gilt für SECUR32.dll und RPCRT4.dll.

Anmerkung: In den Screenshots unten und im Beispielbefehl verwende ich die ältere ClassicStartSetup_4_4_109.exe. Ich habe die gleichen Tests auch mit OpenShellSetup_4_4_126.exe (dem neuesten Nightly Build) durchgeführt – gleiches Ergebnis. Auch keine digitale Signatur vorhanden. Daher lasse ich die alten Screenshots und Befehle im Text.

Stefan Kanthak hat mir erlaubt, einige seiner Test-DLLs zu verwenden, um ClassicStartSetup_4_4_109.exe in einer Testumgebung auszuführen. Hier das Ergebnis:

(Zum Vergrößern klicken)

Ein Versuch, die Optionen anzuzeigen, führte zu einer Warnung, dass eine Malware die Dateien manipuliert haben könnte (Dialogfeld vorne). Danach habe ich das .exe-Installationsprogramm einfach die .msi-Installationsprogramme entpacken lassen. Als ich das 64-Bit-msi-Installationsprogramm ausgeführt habe, wurden keine Warnungen mehr ausgegeben.

Aber die .msi-Dateien, die in der .exe-Installationsdatei enthalten sind, sind derzeit nicht digital signiert. Der Grund dafür: Es handelt sich um Nightly-Builds. An diesem Punkt habe ich alle weiteren Untersuchungen eingestellt. Die Nightly-Builds sind nicht für Endbenutzersysteme gedacht. Warten wir ab, wie die endgültige Version dieses Tools aussieht und ob sie die gleichen Schwachstellen aufweist, wie oben beschrieben.