Open-shell-menu: Should i be concerned about this ?

[thunderpants]

https://borncity.com/win/2018/08/11/psa-classic-shell-is-now-open-shell-menu-and-a-warning/

mentions something about security issues when installing.

[ge0rdi]

Let's address some of article's claims:

At the moment the project produce currently just headlines due to multiple renamings.

Not sure who is producing those _headlines_, but certainly not anyone connected to this project.

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.

If the author was really interested in reasons behind renaming, he could easily ask us (maintainers) on Github.

He'd know that it was Ivo Beltchev (author of ClassicShell) who didn't want us to continue in his product (under the same name). He published the source code so that everyone can use his work as a starting point to create new projects.

Thus we decided to give it new name - ClassicStart. It was similar to original name as our intent was (and I guess still is) to continue in ClassicShell's maintenance and improvements.

Though then somebody discovered existing product - Classic Start Menu - that is basically start menu replacement too and the name sounds very close to what we've picked. And there were concerns that its author may sue us because of the name.

So we had to pick new name, that would hopefully not clash with any existing products.
You can read more about this here.

Now to the security concerns:

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.

Note that this applies to the original ClassicShell installer as well. There was basically no change in installation process of Open-Shell.

Even author admits that it actually is not such issue as he originally claimed:

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

The DLL planting issue (mentioned at the end of article) is probably the only thing that should be of concern.

It is definitely possible that malicious site will _trick_ user to download malicious DLL into standard download folder. And then it will get loaded when user starts (practically) any executable from the same folder.

Though this issue is related practically to most _exe_ installers (including original ClassicShell).

We can try to do something about it, to eliminate this rather minor but still possible threat.
I will create a Github issue for it to not forget.

[coddec]

Add: Generally speaking it's loader problem, currently not only exist on mentioned version.dll. It exist in many places and programs, and it's not Windows specific, this security threat also exist on other platforms such as Linux.

Check out this research paper which made it's way to "ndss-symposium". (For "What is NDSS" click here):
An Evil Copy: How the Loader Betrays You

An Evil Copy: How the Loader Betrays You on NDSS

[XenHat]

Dear article writers: thank you for your interest in our community effort. Please search the issue tracker read the issues associated with any wild claim before writing your articles. We are aware and have addressed many of these. If you find issues that are not already reported, please let us know with a bug report and we'll gladly investigate and/or clarify. For more informal inquiries, we have a Gitter chat room.

[ge0rdi]

I have created issue #72 to address the DLL hijack issue.

Note that even by hijacking DLL and getting into process attacker won't gain much. Because he will run with the same privileges as any normal process. UAC elevation is done by _msiexec_ in trusted way.

Though it is true that attacker may change behavior of running setup, for example use own MSI package to install malicious content. And since we don't have signed binaries (so far), user will be unable to tell whether MSI he is about to install is proper one.

Thus we should rather address the issue.