Nuove informazioni per gli utenti e le parti interessate dello strumento Windows Classic Shell: Il progetto successivo è già stato rinominato di nuovo e ora si chiama Open Shell Menu. Ecco alcune informazioni e un suggerimento sul perché io (attualmente) direi “state attenti”.
C’è un software che si mantiene al centro dell’attenzione attraverso la rinomina. Classificherei il progetto Classic Shell in questa categoria, perché questo progetto è stato rinominato di nuovo.
Alcuni retroscena
Lo sviluppatore di Classic Shell, Ivo Beltchev, ha smesso di sviluppare il software qualche tempo fa. Ma ha dato il codice sorgente alla comunità per ulteriore manutenzione. Ne ho parlato nel mio blog tedesco.
Ma ciò che non è così bello per i miei gusti: Al momento il progetto produce solo titoli a causa di molteplici rinominazioni. Per un breve periodo lo strumento è stato chiamato Classic Start. Poi la comunità ha deciso di rinominarlo alla fine di luglio 2018 in NeoClassic-UI/Menu. Forse ci sono buone ragioni, non so, non sono mai state menzionate.
Il prossimo nuovo nome …
E ora il progetto è stato rinominato in Open-Shell-Menu. Il file di installazione attuale si chiama ora OpenShellSetup_4_4_126.exe, ma la funzionalità probabilmente non è cambiata. Il progetto è disponibile su GitHub, ma non tutti i link sono ancora funzionali. L’attuale Nightly Build è disponibile qui, che scade dopo 6 mesi.
Il lato oscuro di questo progetto: Sicurezza
A parte il ‘un sacco di riso è caduto in Cina, per favore continuate, non c’è niente da vedere’, vorrei sottolineare che dovreste tenere le mani lontane da questo strumento (almeno, finché gli sviluppatori non hanno sistemato alcune cose fondamentali). Perché questo avvertimento?
Sono in contatto con il white hat hacker Stefan Kanthak (vedi) da un po’ (Microsoft lo arruola nella Top 100 MSRC 2017 e anche in altre liste, come top 100 Finders nel 2015). ricercatore nel 2015 (vedi).
Stefan Kanthak ha pubblicato un commento in tedesco, delineando alcune criticità. Ecco un breve estratto:
- Per comodità, gli sviluppatori forniscono un installer .exe (invece di un file .msi). Questo programma di installazione deve essere eseguito con privilegi amministrativi per installare il software. Il programma di installazione scompatta i file richiesti in una directory TEMP (non protetta). Problema: se c’è un malware sul sistema che attualmente viene eseguito solo con i diritti di un account utente limitato, la trappola viene attivata.
- Questo malware può accorgersi del processo di spacchettamento (ci sono API di Windows che possono segnalarlo e chiamare una ‘funzione hook’ del malware). Poi è sufficiente copiare un file DLL con un certo nome nella cartella TEMP (poiché questa non è protetta, ciò è possibile con diritti utente limitati).
- Durante il processo di installazione, il programma di installazione cerca di caricare la presunta DLL di Windows, ma accede alla DLL posta dal malware per le caratteristiche di Windows. E il malware riceve prontamente i diritti amministrativi tramite la DLL.
Questo è noto da tempo come DLL search order hijacking, un potenziale rischio per la sicurezza e dovrebbe essere assolutamente evitato. Stefan Kanthak ha postato alcuni link e ulteriori dettagli nel suo commento tedesco. Come conclusione: Finché il progetto non ha affrontato questi problemi, eviterei/starei attento ad usare tale software.
Addendum: A questo punto devo tirarmi un po’ indietro. Ho dato un’occhiata al programma di installazione (sotto Windows 7). Osservazione interessante: Il lettore tedesco Martin Feuerstein aveva fatto notare in un commento, che l’installer .exe ha un interruttore per estrarre gli installer .msi – può essere visualizzato con /? Quindi è possibile scompattare il .msi e installare la versione a 32/64 bit tramite l’installer .msi.
C’è un’altra osservazione: Apparentemente il .exe installer viene eseguito durante lo scompattamento solo con diritti utente standard, scompatta i file .msi e chiama quello appropriato. Il programma di installazione .msi attiva la richiesta di UAC a causa delle impostazioni nel suo manifesto e installa lo strumento. Questo elimina il vettore di attacco come descritto sopra secondo le mie attuali conoscenze (se l’msi giusto chiama l’UAC può essere controllato nel prompt UAC). Se ci sono nuove scoperte, le aggiungerò.
Addendum 2: secondo Stefan Kanthak il programma di installazione ClassicStartSetup_4_4_109.exe ha le seguenti dipendenze – può essere ottenuto con:
LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe
COMCTL32.dll
VERSION.dll
KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll
E le DLL di cui sopra dipendono da GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll e
SHLWAPI.dll. Da Windows Vista VERSION.dll non è una “DLL conosciuta” e qualsiasi file con quel nome sarà caricato dalla directory dell’applicazione, se presente. Lo stesso vale per SECUR32.dll e RPCRT4.dll.
Nota: Negli screenshot qui sotto e nel comando di esempio, uso il vecchio ClassicStartSetup_4_4_109.exe. Ho fatto gli stessi test anche con OpenShellSetup_4_4_126.exe (la build notturna più recente) – stesso risultato. Inoltre nessuna firma digitale disponibile. Perciò ho lasciato i vecchi screenshot e i comandi all’interno del testo.
Stefan Kanthak mi ha lasciato usare alcune delle sue DLL di prova per eseguire ClassicStartSetup_4_4_109.exe in un ambiente di test. Ecco il risultato:
(Clicca per ingrandire)
Un tentativo di visualizzare le opzioni ha dato come risultato un avviso, che un malware potrebbe aver manipolato i file (finestra di dialogo davanti). In seguito ho lasciato che l’installer .exe estraesse solo gli installer .msi. Quando ho eseguito il programma di installazione msi a 64 bit, non vengono più emessi avvertimenti.
Ma i file .msi inclusi nel file di installazione .exe non sono attualmente firmati digitalmente. Il motivo: Sono build notturne. A quel punto ho fermato ogni ulteriore indagine. Le nightly builds non sono per i sistemi degli utenti finali. Aspettiamo, come appare la versione finale di quello strumento e se ha le stesse vulnerabilità di cui sopra.
Advertising