PSA : Classic Shell est maintenant Open Shell Menu – et un avertissement

Nouvelles informations pour les utilisateurs et les parties intéressées de l’outil Windows Classic Shell : Le projet de suivi a déjà été renommé à nouveau et s’appelle désormais Open Shell Menu. Voici quelques informations et une indication de la raison pour laquelle je dirais (actuellement) « soyez prudent ».

Il y a des logiciels qui se maintiennent au centre de l’attention grâce aux renommages. Je classerais le projet Classic Shell dans cette catégorie, car ce projet a été renommé à nouveau.

Un peu de contexte

Le développeur du Classic Shell, Ivo Beltchev, a cessé de développer le logiciel il y a quelque temps. Mais il a donné le code source à la communauté pour une maintenance ultérieure. J’ai fait un blog à ce sujet au sein de mon blog allemand.

Mais ce qui n’est pas si agréable à mon goût : Le projet produit actuellement juste des titres en raison de multiples renommages. Pendant une courte période, l’outil a été appelé Classic Start. Puis la communauté a décidé de le renommer fin juillet 2018 en NeoClassic-UI/Menu. Peut-être y a-t-il de bonnes raisons, je ne sais pas, elles n’ont jamais été mentionnées.

Le prochain nouveau nom …

Et maintenant le projet a été renommé en Open-Shell-Menu. Le fichier d’installation actuel s’appelle maintenant OpenShellSetup_4_4_126.exe, mais la fonctionnalité n’a probablement pas changé. Le projet est disponible sur GitHub, mais tous les liens ne sont pas encore fonctionnels. La Nightly Build actuelle est disponible ici, qui expire après 6 mois.

Le côté sombre de ce projet : Sécurité

A part le ‘un sac de riz est tombé en Chine, veuillez continuer, rien à voir’, je voudrais signaler que vous devriez garder vos mains loin de cet outil (au moins, jusqu’à ce que les développeurs aient corrigé quelques choses fondamentales). Pourquoi cet avertissement?

Je suis en contact avec le hacker white hat Stefan Kanthak (voir) depuis un moment (Microsoft l’enrôle dans le Top 100 MSRC 2017 et aussi dans d’autres listes, comme le top 100 Finders en 2015). chercheur en 2015 (voir).

Stefan Kanthak a publié un commentaire allemand, soulignant certains problèmes critiques. En voici un bref extrait :

• Pour des raisons de commodité, les développeurs livrent un installateur .exe (au lieu d’un fichier .msi). Ce programme d’installation doit être exécuté avec des privilèges administratifs pour installer le logiciel. Le programme d’installation décompresse les fichiers requis dans un répertoire TEMP (non protégé). Problème : s’il y a un malware sur le système qui ne s’exécute actuellement qu’avec les droits d’un compte utilisateur restreint, le piège est activé.
• Ce malware peut remarquer le processus de déballage (il existe des API Windows qui peuvent le signaler et appeler une ‘fonction hook’ du malware). Ensuite, il suffit de copier un fichier DLL avec un certain nom dans le dossier TEMP (puisque celui-ci n’est pas protégé, cela est possible avec des droits d’utilisateur limités).
• Pendant le processus d’installation, le programme d’installation tente de charger la DLL supposée de Windows, mais accède à la DLL placée par le malware en raison des caractéristiques de Windows. Et le malware reçoit rapidement des droits d’administration via la DLL.

Ceci est connu depuis longtemps sous le nom de détournement d’ordre de recherche de DLL, un risque potentiel pour la sécurité et doit être absolument évité. Stefan Kanthak a posté quelques liens et des détails supplémentaires dans son commentaire allemand. En conclusion : Tant que le projet n’a pas abordé ces problèmes, j’éviterais/serais prudent en utilisant un tel logiciel.

Addendum : À ce stade, je dois me retirer un peu. J’ai jeté un coup d’œil à l’installateur (sous Windows 7). Observation intéressante : Le lecteur allemand Martin Feuerstein avait fait remarquer dans un commentaire, que l’installateur .exe a un commutateur pour extraire les installateurs .msi – peut être affiché avec / ? Vous pouvez donc décompresser le .msi et installer la version 32-/64 bits via l’installateur .msi.

Il y a une autre observation : Apparemment, l’installateur .exe s’exécute pendant le déballage uniquement avec des droits d’utilisateur standard, il déballe les fichiers .msi et appelle celui qui convient. Le programme d’installation .msi active l’invite UAC en raison des paramètres de son manifeste et installe l’outil. Ceci élimine le vecteur d’attaque tel que décrit ci-dessus selon mes connaissances actuelles (si le bon msi appelle l’UAC peut être vérifié dans l’invite UAC). S’il y a de nouvelles découvertes, je les ajouterai.

Addendum 2 : Selon Stefan Kanthak, l’installateur ClassicStartSetup_4_4_109.exe a les dépendances suivantes – peut être obtenu avec:

LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe

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

Et les DLLs ci-dessus dépendent de GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll et
SHLWAPI.dll. Depuis Windows Vista VERSION.dll n’est pas une « DLL connue » et tout fichier portant ce nom sera chargé depuis le répertoire de l’application, s’il est présent. Il en va de même pour SECUR32.dll et RPCRT4.dll.

Note : Dans les captures d’écran ci-dessous et dans l’exemple de commande, j’utilise l’ancien ClassicStartSetup_4_4_109.exe. J’ai effectué les mêmes tests avec OpenShellSetup_4_4_126.exe (la version nocturne la plus récente) – même résultat. Pas de signature digitale disponible non plus. Je laisse donc les anciennes captures d’écran et commandes dans le texte.

Stefan Kanthak m’a laissé utiliser certaines de ses DLL de test pour exécuter ClassicStartSetup_4_4_109.exe dans un environnement de test. Voici le résultat :

(Cliquez pour zoomer)

Une tentative d’affichage des options a donné lieu à un avertissement, qu’un malware pourrait avoir manipulé les fichiers (boîte de dialogue au recto). Ensuite, j’ai laissé l’installateur .exe juste extraire les installateurs .msi. Lorsque j’ai exécuté l’installateur msi 64 bits, aucun autre avertissement n’est émis.

Mais les fichiers .msi inclus dans le fichier d’installation .exe ne sont actuellement pas signés numériquement. La raison : Ce sont des nightly builds. À ce stade, j’ai arrêté toute investigation supplémentaire. Les nightly builds ne sont pas destinés aux systèmes des utilisateurs finaux. Attendons, à quoi ressemble la version finale de cet outil et si elle présente les mêmes vulnérabilités que celles décrites ci-dessus.