[English]Ich muss leider erneut ein Thema hochholen, welches die "Kompetenz Microsofts" in Sachen funktionierender und sicherer Software in den Fokus stellt. Es geht um Microsofts Printer Metadata Troubleshooter Tool, das unter KB5034510 bereitgestellt wird. Es soll die durch Updates hervorgerufenen Probleme mit Druckersymbolen und der installierten HP Smart-App beheben. Das Tool funktionierte aber unter RDS 2016 nicht, sondern wirft einen Zugriffsfehler. Die Entwickler haben beim Zusammenklicken des Tools gleich an mehreren Stellen versagt.
Anzeige
Worum geht es bei KB5034510?
Seit Ende November 2023 sahen sich Nutzer mit dem Problem konfrontiert, dass sich plötzlich eine "HP Smart" Drucker-App auf ihren Systemen mit Windows 10 und Windows 11 installiert hat. Das galt auch für Systeme, an denen überhaupt kein HP-Drucker angeschlossen geschweige denn eingerichtet war.
Ich hatte im Blog-Beitrag Windows 10/11: "HP Smart" Drucker-App wird ungefragt installiert über das Problem berichtet. Microsoft bestätigte zum 4. Dezember 2023 das Problem und schrieb, dass zusätzliche Druckerbezeichnungen und Symbole verändert worden sein können. Obiger Screenshot zeigt beispielsweise, dass der Microsoft XPS Document Writer angeblich ein HP LaserJet ist. Mehr Details finden sich in meinem Beitrag Microsoft untersucht HP Smart-App-Installation und Änderungen unter Windows.
Mitte Dezember 2023 stellte Microsoft dann das Microsoft Printer Metadata Troubleshooter Tool unter dem Support-Beitrag KB5034510 bereit. Das Tool soll nun Administratoren helfen, das oben skizzierte Problem mit der "HP Smart" Drucker-App und den veränderten Druckereinträgen unter Windows zu bereinigen. Das Tool deinstalliert ggf. die "HP Smart" Drucker-App und korrigiert die Metadaten für Drucker, so dass Windows sich die korrekten Bezeichnungen und Symbole für Drucker von den Microsoft-Servern herunterladen kann. Ich hatte einige Hinweise im Blog-Beitrag Microsofts Printer Metadata Troubleshooter Tool (KB5034510) für HP Smart-App-Problem zum Tool gegeben.
Anzeige
RDS: Das Tool scheitert mit 0x80070005
Gleich mehrere Blog-Leser berichteten, dass das Microsoft Printer Metadata Troubleshooter Tool unter RSD 2016 (Remote Desktop Services auf Windows Server 2016) scheitere. Ein Benutzer schreibt hier, dass das Tool mit "Troubleshooter failed with: 0x80070005" endet, wenn es auf 2016 RDS ausgeführt werde.
Der Fehlercode steht für ERROR_ACCESS_DENIED, das Tool kann also auf irgend ein Ziel nicht schreibend zugreifen, braucht diesen Zugriff aber, um die Metadaten anzupassen. Stefan Kanthak vermutet hier, dass der Zugriff zum Schreiben auf einem Objekt scheitert, welches zum TrustedInstaller gehört.
Kanthak weist darauf hin, dass Programme in ihren Schreibprozessen diesen Fehler durch Aktivieren der Privilegien Backup und Restore vermeiden können. Mit diesen Privilegien kann der Prozess auf die Ressource schreiben (die Zugriffsrechte werden dann ignoriert). Kanthak hat in seinem Kommentar Beispiele verlinkt.
Weitere Fails
An dieser Stelle noch ein paar Feinheiten aufgewischt, die die meisten Leute nicht interessieren, wenn das Tool irgend etwas macht, die Stefan Kanthak aber sofort aufgefallen sind.
Bei Berechtigungen gepatzt
Geht man in Microsofts Support-Beitrag KB5034510, werden dort diverse Restriktionen angegeben. So muss das Tool aus einer administrativen Eingabeaufforderung gestartet werden. Microsofts Entwickler geben auch Möglichkeiten vor, das Tool über geplante Aufgaben mit entsprechenden Berechtigungen auszuführen. Was ein Aufriss für die Administratoren.
Stefan Kanthak weist in diesem Kommentar darauf hin, dass die Microsoft-Entwickler hier eine unnötige Hürde geschaffen hätten. Ein ausführbares Programm beinhaltet in der .exe-Datei eine sogenannte Manifest-Datei, die festlegt, wie dieses auszuführen ist. Microsofts Entwickler haben dort im Manifest:
<requestedExecutionLevel level='asInvoker' uiAccess='false' />
festgelegt – wohl um den Microsoft Standardvorgaben für Programme zu entsprechen, die mit Standard-Privilegien auszuführen sind. Man hätte aber auch "requireAdministrator" als level angeben können. Das führt dazu, dass eine Anwendung sich die benötigten Administratorrechte beim Start über die Benutzerkontensteuerung vom Benutzer anfordert. Dann hätte ein Doppelklick auf die Programmdatei genügt.
Die DLL-Hijacking-Falle
Ein weiterer Hinweis in diesem Kommentar geht darauf ein, dass Microsoft versäumt habe zu erwähnen, dass das Verzeichnis für die Ausführung des Programms PrintMetadataTroubleshooterX86.exe niemals das Temp-Verzeichnis oder das Download-Verzeichnis des Nutzerkontos sein sollte.
Vielmehr gilt es, ein eigenes Verzeichnis anzulegen, in das nur ein Administrator schreiben darf. Das Verzeichnis muss leer sein, bevor die Programmdatei PrintMetadataTroubleshooterX86.exe dort hin kopiert wird.
Der Hintergrund ist, dass ein Administrator nur so sicher sein kann, dass beim Aufruf der Programmdatei PrintMetadataTroubleshooterX86.exe nichts als Beifang im Programmordner mit ausgeführt wird.
Stefan Kanthak schreibt aber, dass die Anwendung die Datei WINSPOOL.drv ausführen könnte, sofern sich diese im Programmverzeichnis befindet. Damit wäre das Tor für DLL-Hijacking geöffnet, denn ein nicht privilegierter Angreifer könnte Malwaredateien diesen Namens in den Programmordner Temp oder Downloads schreiben. Beim Aufruf von PrintMetadataTroubleshooterX86.exe würden die betreffenden Malwaredateien mit Administrator- oder SYSTEM-Privilegien ausgeführt.
Einfach um den Ansatz mal zu verdeutlichen, habe ich einen kurzen Test laufen lassen (Stefan Kanthak hat mich dazu bewogen, weil mein Testbett aus Windows 7-Zeiten nicht mehr funktioniert). Obiger Screenshot zeigt meinen extra angelegten Testordner, in den ich die PrintMetadataTroubleshooterX86.exe von Microsoft kopiert habe. Da der Order sonst leer war, würde ich sofort erkennen, wenn dort etwas manipuliert wird.
Dann habe ich zum Test eine leere Datei WINSPOOL.drv angelegt, um zu sehen, was passiert. Die PrintMetadataTroubleshooterX86.exe von Microsoft müsste sich bei "sauberer" Programmierung weiterhin ohne Probleme ausführen lassen.
Stattdessen bekomme ich von PrintMetadataTroubleshooterX86.exe ein Dialogfeld "Ungültiges Bild" angezeigt, wo bemängelt wird, dass meine Datei WINSPOOL.drv nicht für die Ausführung von Windows vorgesehen sei oder einen Fehler enthält.
Ja nee, is klar, eine leere Datei kann nicht ausgeführte werden – der Fehlerdialog hat Recht. Die "Experten" aus Redmond offenbaren in diesem Konstrukt aber, dass die PrintMetadataTroubleshooterX86.exe keine Vorgaben machen, wo abhängige Dateien zu laden sind, sondern verwenden die (entgegen Microsofts eigenen Programmiervorgaben) die Standardsuchvorgaben aus Windows zu Laden. Und dann werden halt die Dateien mit dem betreffenden Namen aus dem Programmverzeichnis nachgeladen.
Gelingt es einer Malware den Temp– oder Download-Ordner mit solchen Dateien zu instrumentieren, und wird die Datei PrintMetadataTroubleshooterX86.exe dort vom Administrator aus einer administrativen Eingabeaufforderung ausgeführt, lädt das Tool die Schadsoftware und führt diese mit Administratorrechten aus. Das ist dann der Jackpot.
Ergänzung: Microsoft hat auf Grund der von Stefan Kanthak gemeldeten Remote Code Execution-Schwachstelle das Tool mit einem Update versehen. Ich habe die Dateils im Blog-Beitrag Microsoft patcht CVE-2024-21325 im Printer Metadata Troubleshooter Tool (KB5034510) veröffentlicht.
Ähnliche Artikel:
Windows 10/11: "HP Smart" Drucker-App wird ungefragt installiert
Microsoft untersucht HP Smart-App-Installation und Änderungen unter Windows
Microsofts Printer Metadata Troubleshooter Tool (KB5034510) für HP Smart-App-Problem
Fails beim Microsofts Printer Metadata Troubleshooter Tool (KB5034510; HP Smart-App-Fixer
Anzeige
Der (deutsche) Text "Ungültiges Bild" im Titel der Meldungsbox ist ebenfalls eine allerdings erst 30 (in Worten: DREISSIG) Jahre alte GLANZLEISTUNG; der englische Originaltext "Invalid Image" ist keinen Deut besser, und beide Verstossen gegen M$FTs eigene Vorgaben, auch bzw. gerade für Otto Normalmissbraucher (leicht) VERSTÄNDLICHE Meldungen auszugeben: M$FT verwendet die hier dummerweise sinnentstellende Kurzform "Image" anstelle der Langform "Portable Executable Image File". Siehe auch https://msdn.microsoft.com/en-us/library/gg463119.aspx alias https://msdn.microsoft.com/en-us/library/ms680547.aspx
JFTR: der symbolische Name des NTSTATUS-Code 0xC0000020 lautet STATUS_INVALID_FILE_FOR_SECTION (Windows kann nur NICHT-leere Dateien "memory mapped" laden/öffnen).
Es war damals eine Glanzleistung von Microsoft als Server 2016 im wesentlichen Windows 10 zu verkaufen. Mit einigen Eigenarten, die man sich auf einem Server nicht gewünscht hätte (z.B. das im Default jeder User Windows-Updates installieren konnte).
Man hatte hier den RDS schlicht aus den Augen verloren und angenommen, dass zugreifende User auf dem Server auch entsprechende Befugnisse hätten.
Besser wurde das ganze mit der Zeit nicht, da sich Win10 immer weiter von 1607 wegbewegt hatte und das beim Server eben nicht stattfand und damit Sachen die Bei neueren Windows 10 funktionierten eventuell beim Server Probleme machten.
Die Installation HP Smart App und falsche Druckerbilder entstand ohne Zutun von Administratoren, also solle Microsoft das auch ohne Zutun von Administratoren beheben können. Unverständlich, dass hier irgendwelche Tools ausgeführt werden müssen.
Ist doch beim Exchange genau das gleiche. Hier sollen Admins auch ständig MANUELL etwas tun :( …
ist doch schön. So sichert MS vielen Admins den Arbeitsplatz oder motiert zum wechseln in die höchst lukrative Cloud
win win
Sind automatisiert übersetzte Fehlermeldungen nicht ein Quell der Freude und Heiterkeit?
https://www.neowin.net/news/microsoft-quietly-updates-the-fix-for-hp-smart-auto-install-bug-on-windows-1110servers/