Ny information til brugere og interesserede af Windows-værktøjet Classic Shell: Opfølgningsprojektet er allerede blevet omdøbt igen og hedder nu Open Shell Menu. Her er lidt information og et hint, hvorfor jeg (i øjeblikket) vil sige “pas på””.
Der er software, der holder sig selv i fokus ved at omdøbe sig selv. Jeg vil klassificere Classic Shell-projektet i denne kategori, for dette projekt er blevet omdøbt igen.
En del baggrund
Udvikleren af Classic Shell, Ivo Beltchev, stoppede med at udvikle softwaren for et stykke tid siden. Men han gav kildekoden til fællesskabet med henblik på yderligere vedligeholdelse. Jeg har blogget om det inden for min tyske blog.
Men hvad er ikke så rart for min smag: I øjeblikket producerer projektet i øjeblikket bare overskrifter på grund af flere omdøbninger. I en kort periode hed værktøjet Classic Start. Så besluttede fællesskabet at omdøbe det i slutningen af juli 2018 til NeoClassic-UI/Menu. Måske er der gode grunde, jeg ved det ikke, de er aldrig blevet nævnt.
Det næste nye navn …
Og nu er projektet blevet omdøbt til Open-Shell-Menu. Den aktuelle installationsfil hedder nu OpenShellSetup_4_4_126.exe, men funktionaliteten er formentlig ikke ændret. Projektet er tilgængeligt på GitHub, men ikke alle links er funktionelle endnu. Den aktuelle Nightly Build er tilgængelig her, som udløber efter 6 måneder.
Den mørke side af dette projekt: Sikkerhed
Fra og med “en sæk ris faldt om i Kina, fortsæt venligst, der er intet at se”, vil jeg gerne påpege, at du bør holde dine hænder væk fra dette værktøj (i det mindste indtil udviklerne har rettet et par grundlæggende ting). Hvorfor denne advarsel?
Jeg har været i kontakt med white hat hacker Stefan Kanthak (se) siden et stykke tid (Microsoft har hvervet ham i Top 100 MSRC 2017 og også i andre lister, som f.eks. top 100 Finders i 2015). researcher i 2015 (se).
Stefan Kanthak har skrevet en tysk kommentar, hvori han skitserer nogle kritiske spørgsmål. Her er et kort uddrag:
- For nemheds skyld leverer udviklerne et .exe-installationsprogram (i stedet for en .msi-fil). Dette installationsprogram skal udføres med administrative rettigheder for at installere softwaren. Installationsprogrammet pakker de nødvendige filer ud i en (ubeskyttet) TEMP-mappe. Problem: Hvis der er malware på systemet, som i øjeblikket kun kører med rettighederne for en begrænset brugerkonto, aktiveres fælden.
- Denne malware kan bemærke udpakningsprocessen (der findes Windows API’er, der kan rapportere dette og kalde en “hook-funktion” i malware). Derefter er det tilstrækkeligt at kopiere en DLL-fil med et bestemt navn til TEMP-mappen (da denne er ubeskyttet, er dette muligt med begrænsede brugerrettigheder).
- Under installationsprocessen forsøger installationsprogrammet at indlæse den formodede Windows DLL, men får adgang til den DLL, der er placeret af malware på grund af Windows-egenskaber. Og malware får straks administrative rettigheder via DLL’en.
Dette er kendt siden lang tid som DLL-søgningsordrekapring, en potentiel sikkerhedsrisiko, og bør absolut undgås. Stefan Kanthak har lagt nogle links og yderligere detaljer op i sin tyske kommentar. Som en konklusion: Så længe projektet ikke behandlede disse problemer, ville jeg undgå/ være forsigtig med at bruge sådan software.
Addendum: På dette punkt er jeg nødt til at trække mig en smule tilbage. Jeg tog et kig på installationsprogrammet (under Windows 7). Interessant observation: En interessant observation: Den tyske læser Martin Feuerstein havde i en kommentar påpeget, at .exe-installationsprogrammet har en switch til udpakning af .msi-installationsprogrammerne – kan vises med /? Så du kan udpakke .msi-versionen og installere 32-/64-bit versionen via .msi-installationsprogrammet.
Der er en anden observation: Tilsyneladende kører .exe-installationsprogrammet under udpakning kun med standardbrugerrettigheder, pakker .msi-filerne ud og kalder den relevante. .msi-installationsprogrammet aktiverer UAC-prompten på grund af indstillinger i dets manifest og installerer værktøjet. Dette eliminerer angrebsvektoren som beskrevet ovenfor i henhold til min nuværende viden (om den rigtige msi kalder UAC kan kontrolleres i UAC-prompten). Hvis der er nye fund, vil jeg tilføje dem.
Addendum 2: Ifølge Stefan Kanthak har installationsprogrammet ClassicStartSetup_4_4_109.exe følgende afhængigheder – kan hentes med:
LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe
COMCTL32.dll
VERSION.dll
KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll
Og ovenstående DLL’er er afhængige af GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll og
SHLWAPI.dll. Siden Windows Vista VERSION.dll ikke er en “kendt DLL”, og enhver fil med det navn vil blive indlæst fra programmets mappe, hvis den er til stede. Det samme gælder SECUR32.dll og RPCRT4.dll.
Bemærk: I skærmbillederne nedenfor og i prøvekommandoen bruger jeg den ældre ClassicStartSetup_4_4_4_109.exe. Jeg rundede de samme tests også med OpenShellSetup_4_4_4_126.exe (den seneste nightly build) – samme resultat. Der er heller ingen digital signatur tilgængelig. Derfor lader jeg de gamle skærmbilleder og kommandoer stå i teksten.
Stefan Kanthak lod mig bruge nogle af hans test-DLL’er til at køre ClassicStartSetup_4_4_4_109.exe i et testmiljø. Her er resultatet:
(Klik for at zoome)
Et forsøg på at vise indstillingerne resulterede i en advarsel om, at en malware kunne have manipuleret filerne (dialogboks foran). Herefter lod jeg .exe-installationsprogrammet bare udpakke .msi-installationsprogrammerne. Da jeg udførte 64 bit msi-installationsprogrammet, blev der ikke udsendt flere advarsler.
Men de .msi-filer, der er inkluderet i .exe-installationsfilen, er i øjeblikket ikke digitalt signeret. Årsagen: De er nightly builds. På det tidspunkt stoppede jeg alle yderligere undersøgelser. Nightly builds er ikke beregnet til slutbrugersystemer. Lad os vente, hvordan den endelige version af dette værktøj ser ud, og om det har de samme sårbarheder som skitseret ovenfor.
Advertising