PSA: Classic Shell is now Open Shell Menu – and a warning

[German]New information for users and interested parties of the Windows tool Classic Shell: The follow-up project has already been renamed again and is now called Open Shell Menu. Here's some information and a hint why I (currently) would say 'be careful''.

There is software that keeps itself in the focus of attention through renaming. I would classify the Classic Shell project in this category, because this project has been renamed again.

Some Background

The developer of the Classic Shell, Ivo Beltchev, stopped developing the software some time ago. But he gave the source code to the community for further maintenance. I've blogged about that within my German blog.

But what is not so nice for my taste: At the moment the project produce currently just headlines due to multiple renamings. For a short time the tool was called Classic Start. Then the community decided to rename it end of July 2018 to NeoClassic-UI/Menu. Maybe there are good reasons, I don't know, they have never been mentioned.

The next new name …

And now the project has been renamed to Open-Shell-Menu. The current installation file is now called OpenShellSetup_4_4_126.exe, but the functionality has probably not changed. The project is available on GitHub, but not all links are functional yet. The current Nightly Build is available here, which expires after 6 months.

The dark side of this project: Security

Beside the 'a sack rice fell over in China, please continue, nothing to see', I would like to point out that you should keep your hands away from this tool (at least, until the developers has fixed a few fundamental things). Why this warning?

I'm in touch with white hat hacker Stefan Kanthak (see) since a while (Microsoft enlists him in the Top 100 MSRC 2017 and also in other lists, like top 100 Finders in 2015). researcher in 2015 (see).

Stefan Kanthak has posted a German comment, outlining some critical issues. Here is a brief excerpt:

• For convenience, the developers deliver an .exe installer (instead of an .msi file). This installer need to be executed with administrative privileges to install the software. The installer unpacks the required files into an (unprotected) TEMP directory. Problem: If there is malware on the system that currently only runs with the rights of a restricted user account, the trap is activated.
• This malware may notice the unpacking process (there are Windows APIs that can report this and call a 'hook function' of the malware). Then it is sufficient to copy a DLL file with a certain name into the TEMP folder (since this is unprotected, this is possible with limited user rights).
• During the installation process, the installer tries to load the supposed Windows DLL, but accesses the DLL placed by the malware due to Windows characteristics. And the malware promptly receives administrative rights via the DLL.

This is known since long time as DLL search order hijacking, a potential security risk and should be absolutely avoided. Stefan Kanthak has posted some links and further details in his German comment. As a conclusion: As long as the project didn't address these issues, I would avoid/be careful using such software.

Addendum: At this point I have to pull back a little bit. I took a look at the installer (under Windows 7). Interesting observation: German reader Martin Feuerstein had pointed out in a comment, that the .exe installer has a switch for extracting the .msi installers – can be displayed with /? So you can unpack the .msi and install the 32-/64-bit version via .msi installer.

There is another observation: Apparently the .exe installer runs during unpacking only with standard user rights, unpacks the .msi files and calls the appropriate one. The .msi installer activates the UAC prompt due to settings within it's manifest and installs the tool. This eliminate the attack vector as described above according to my current knowledge (whether the right msi calls the UAC can be checked in the UAC prompt). If there are new findings, I will add them.

Addendum 2: According to Stefan Kanthak the installer ClassicStartSetup_4_4_109.exe has the following dependencies – may be obtained with:

LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe

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

And the above DLLs depends on GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll and
SHLWAPI.dll. Since Windows Vista VERSION.dll isn't a "known DLL" and any file with that name will be loaded from the application's directory, if present. Same applies to SECUR32.dll and RPCRT4.dll.

Note: Within the screenshots below and within the sample command, I uses the older ClassicStartSetup_4_4_109.exe. I rund the same tests also with OpenShellSetup_4_4_126.exe (the most recent nightly build) – same result. Also no digitale signature available. Therefor I let the old screenshots and commands within the text.

Stefan Kanthak let me use some of his test DLLs to run ClassicStartSetup_4_4_109.exe in a test environment. Here is the result:

(Click to zoom)

An attempt to display the options resulted in a warning, that a malware could have manipulated the files (dialog box in front). Afterwards I let the .exe installer just extract the .msi installers. When I executed the 64 bit msi installer, no more warnings are issued.

But the .msi files included in the .exe installer file are currently not digitally signed. The reason: They are nightly builds. At that point I stopped any further investigations. The nightly builds are not for end user systems. Let's wait, how the final version of that tool looks like and if it has the same vulnerabilities as outlined above.