[German]Unfortunately, I have to bring up another topic that focuses on Microsoft's "competence" in terms of writing secure software. It's about Microsoft's Printer Metadata Troubleshooter Tool, which is provided under KB5034510. It is intended to resolve issues with printer icons and the installed HP Smart app caused by updates. However, the tool does not work under RDS 2016, but throws an access error. The developers failed in several places when creating the tool.
What is KB5034510 about?
Since the end of November 2023, users have been confronted with the problem that an "HP Smart" printer app has suddenly been installed on their systems with Windows 10 and Windows 11. This also applied to systems to which no HP printer was connected at all, let alone set up.
I reported on the problem in the blog post Windows 10/11: "HP Smart" printer app is installed without permission. Microsoft confirmed the issue on December 4, 2023 and wrote that additional printer names and icons may have been changed. The screenshot above shows, for example, that the Microsoft XPS Document Writer is supposedly an HP LaserJet. More details can be found in my article Microsoft investigates HP Smart App installation and other related issues on Windows.
In mid-December 2023, Microsoft then made the Microsoft Printer Metadata Troubleshooter Tool available under support article KB5034510. The tool is now intended to help administrators resolve the problem outlined above with the "HP Smart" printer app and the changed printer entries under Windows. The tool uninstalls the "HP Smart" printer app if necessary and corrects the metadata for printers so that Windows can download the correct names and symbols for printers from the Microsoft servers. I had given some hints about the tool in the blog post Microsoft Printer Metadata Troubleshooter Tool (KB5034510) fixes HP Smart App bug.
RDS: The tool fails with 0x80070005
Several German blog readers have reported that the Microsoft Printer Metadata Troubleshooter Tool fails on RSD 2016 (Remote Desktop Services on Windows Server 2016). The tool ends with "Troubleshooter failed with: 0x80070005" when run on 2016 RDS.
The error code stands for ERROR_ACCESS_DENIED, so the tool cannot write to any target, but needs this access to adjust the metadata. Security expert Stefan Kanthak suspects that write access to an object belonging to the TrustedInstaller is failing.
Kanthak points out that programs can avoid this error in their write processes by activating the Backup and Restore privileges. With these privileges, the process can write to the resource (the access rights are then ignored). Kanthak has linked examples in his comment.
More fails
At this point, I would like to point out a few fails of that tool, that most people are not aware of, but which Stefan Kanthak noticed immediately.
Failure with permissions
If you go to Microsoft's support article KB5034510, various restrictions are specified there. For example, the tool must be started from an administrative command prompt. Microsoft's developers also provide options for running the tool via scheduled tasks with appropriate authorizations. What a fuss for the administrators.
Stefan Kanthak points out in this comment that the Microsoft developers have created an unnecessary hurdle here. An executable program contains a so-called manifest file in the .exe file, which specifies how it is to be executed. Microsoft's developers have defined this in the manifest:
<requestedExecutionLevel level='asInvoker' uiAccess='false' />
probably to comply with the Microsoft standard specifications for programs that are to be executed with standard privileges. However, you could also have specified "requireAdministrator" as the level. This would result in an application requesting the required administrator rights from the user via the user account control at startup. A double-click on the program file would then have sufficed.
The DLL hijacking trap
Another note in this German comment points out that Microsoft neglected to mention that the directory for running the PrintMetadataTroubleshooterX86.exe program should never be the temp directory or the download directory of the user account.
Instead, a separate directory must be created to which only an administrator may write. The directory must be empty before the file PrintMetadataTroubleshooterX86.exe is copied there.
The reason for this is that this is the only way an administrator can be sure that when the PrintMetadataTroubleshooterX86.exe program file is called up, nothing is executed in the program folder as by-catch.
However, Stefan Kanthak noticed that the application could execute the WINSPOOL.drv file if it is located in the program directory. This would open the door to DLL hijacking, as a non-privileged attacker could write malware files with this name to the Temp or Downloads program folder. When PrintMetadataTroubleshooterX86.exe is called, the malware files in question would be executed with administrator or SYSTEM privileges.
Just to illustrate the approach, I ran a short test (Stefan Kanthak persuaded me to do this because my test bed for Windows 7 no longer works in Windows 10). The screenshot above shows my created test folder, into which I copied the the Microsoft file PrintMetadataTroubleshooterX86.exe. As the folder was otherwise empty, I would immediately recognize if something was being manipulated there.
I then created an empty WINSPOOL.drv file as a test to see what happened. The PrintMetadataTroubleshooterX86.exe from Microsoft should continue to run without any problems if the developers has implemented the tool in a professional way, along to Microsofts own security guidelines.
Instead, PrintMetadataTroubleshooterX86.exe displays the error dialog shown above – it's a German dialog box with the title "PrintMetadataTroubleshooterX86.exe – Invalid image" and stating that my WINSPOOL.drv file is not intended for Windows execution or contains an error.
Of course, an empty file cannot be executed – the error dialog is right. However, the "experts" from Redmond reveal that PrintMetadataTroubleshooterX86.exe does not specify where dependent files are to be loaded, but uses the search defaults from Windows for loading (contrary to Microsoft's own programming specifications). And then the files with the relevant name are loaded from the program's own directory.
If a malware succeeds in instrumenting the temp or download folder with such files and the PrintMetadataTroubleshooterX86.exe file is executed there by the administrator from an administrative command prompt, the tool loads the malware and executes it with administrator rights. This is the jackpot.
Microsoft values complexity over reliability. Hence all the reports on this fantastically helpful website.
Hi, same error on Windows 2012R2 RDS FARM.