PSA: Classic Shell är nu Open Shell Menu – och en varning

Ny information för användare och intresserade av Windows-verktyget Classic Shell: Uppföljningsprojektet har redan bytt namn igen och heter nu Open Shell Menu. Här är lite information och en antydan om varför jag (för närvarande) skulle säga ”var försiktig””.

Det finns programvaror som håller sig i fokus för uppmärksamheten genom att byta namn. Jag skulle klassificera Classic Shell-projektet i denna kategori, eftersom detta projekt har bytt namn igen.

En del bakgrund

Utvecklaren av Classic Shell, Ivo Beltchev, slutade utveckla programvaran för en tid sedan. Men han gav källkoden till gemenskapen för fortsatt underhåll. Jag har bloggat om detta inom min tyska blogg.

Men vad är inte så trevligt för min smak: För tillfället producerar projektet för närvarande bara rubriker på grund av flera namnbyten. Under en kort tid hette verktyget Classic Start. Sedan beslutade gemenskapen att döpa om det i slutet av juli 2018 till NeoClassic-UI/Menu. Kanske finns det goda skäl, jag vet inte, de har aldrig nämnts.

Nästa nya namn …

Och nu har projektet bytt namn till Open-Shell-Menu. Den aktuella installationsfilen heter nu OpenShellSetup_4_4_126.exe, men funktionaliteten har förmodligen inte ändrats. Projektet finns på GitHub, men alla länkar fungerar inte ännu. Den aktuella Nightly Build finns här, som upphör att gälla efter 6 månader.

Den mörka sidan av detta projekt: Säkerhet

Förutom ”en säck ris föll omkull i Kina, fortsätt, det finns inget att se” vill jag påpeka att du bör hålla händerna borta från det här verktyget (åtminstone tills utvecklarna har åtgärdat några grundläggande saker). Varför denna varning?

Jag är i kontakt med white hat-hackern Stefan Kanthak (se) sedan ett tag tillbaka (Microsoft värvar honom i Top 100 MSRC 2017 och även i andra listor, som top 100 Finders 2015). Researcher 2015 (se).

Stefan Kanthak har skrivit en tysk kommentar där han redogör för några kritiska frågor. Här är ett kort utdrag:

• För bekvämlighetens skull levererar utvecklarna ett .exe-installationsprogram (istället för en .msi-fil). Detta installationsprogram måste exekveras med administratörsrättigheter för att installera programvaran. Installationsprogrammet packar upp de nödvändiga filerna i en (oskyddad) TEMP-katalog. Problem: Om det finns skadlig programvara på systemet som för närvarande endast körs med rättigheterna för ett begränsat användarkonto, aktiveras fällan.
• Denna skadlig programvara kan lägga märke till uppackningsprocessen (det finns Windows API:er som kan rapportera detta och anropa en ”hook-funktion” i den skadlig programvara). Då räcker det med att kopiera en DLL-fil med ett visst namn till TEMP-mappen (eftersom denna är oskyddad är detta möjligt med begränsade användarrättigheter).
• Under installationsprocessen försöker installationsprogrammet ladda den förmodade Windows-DLL:en, men får tillgång till den DLL:en som skadlig kod placerats av den skadliga programvaran på grund av Windows-egenskaperna. Och det skadliga programmet får snabbt administrativa rättigheter via DLL:n.

Detta är känt sedan länge som DLL search order hijacking, en potentiell säkerhetsrisk och bör absolut undvikas. Stefan Kanthak har lagt upp några länkar och ytterligare detaljer i sin tyska kommentar. Som en slutsats: Så länge projektet inte tar itu med dessa problem skulle jag undvika/vara försiktig med att använda sådan programvara.

Addendum: I det här läget måste jag dra mig tillbaka lite grann. Jag tog en titt på installationsprogrammet (under Windows 7). Intressant observation: Tyska läsaren Martin Feuerstein hade påpekat i en kommentar att .exe installationsprogrammet har en switch för att extrahera .msi installationsprogrammen – kan visas med /? Så du kan packa upp .msi och installera 32-/64-bitarsversionen via .msi-installer.

Det finns en annan observation: Tydligen körs .exe-installationsprogrammet under uppackning endast med standardanvändarrättigheter, packar upp .msi-filerna och anropar den lämpliga. .msi-installationsprogrammet aktiverar UAC-prompten på grund av inställningar i dess manifest och installerar verktyget. Detta eliminerar angreppsvektorn enligt beskrivningen ovan enligt min nuvarande kunskap (om rätt msi kallar UAC kan kontrolleras i UAC-prompten). Om det finns nya upptäckter kommer jag att lägga till dem.

Addendum 2: Enligt Stefan Kanthak har installationsprogrammet ClassicStartSetup_4_4_109.exe följande beroenden – kan erhållas med:

LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe

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

Och ovanstående DLL:er är beroende av GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll och
SHLWAPI.dll. Sedan Windows Vista VERSION.dll inte är en ”känd DLL” och alla filer med det namnet kommer att laddas från programkatalogen, om de finns. Samma sak gäller för SECUR32.dll och RPCRT4.dll.

Notera: I skärmdumparna nedan och i exempelkommandot använder jag den äldre ClassicStartSetup_4_4_109.exe. Jag genomförde samma tester även med OpenShellSetup_4_4_126.exe (den senaste nightly build) – samma resultat. Det finns inte heller någon digital signatur tillgänglig. Därför låter jag de gamla skärmdumparna och kommandona stå kvar i texten.

Stefan Kanthak lät mig använda några av hans test-DLL:er för att köra ClassicStartSetup_4_4_109.exe i en testmiljö. Här är resultatet:

(Klicka för att zooma)

Ett försök att visa alternativen resulterade i en varning om att ett skadligt program kan ha manipulerat filerna (dialogrutan längst fram). Därefter lät jag .exe-installationsprogrammet bara extrahera .msi-installationsprogrammen. När jag exekverade 64-bitars msi-installationsprogrammet utfärdades inga fler varningar.

Men .msi-filerna som ingår i .exe-installationsfilen är för närvarande inte digitalt signerade. Anledningen: De är nightly builds. I det läget avbröt jag alla ytterligare undersökningar. Nightly builds är inte avsedda för slutanvändarsystem. Låt oss vänta, hur den slutliga versionen av det verktyget ser ut och om den har samma sårbarheter som beskrivs ovan.