Noi informații pentru utilizatorii și cei interesați de instrumentul Windows Classic Shell: Proiectul subsecvent a fost deja redenumit din nou și se numește acum Open Shell Menu. Iată câteva informații și un indiciu de ce aș spune (în prezent) „aveți grijă””.
Există un software care se menține în centrul atenției prin redenumire. Aș clasifica proiectul Classic Shell în această categorie, deoarece acest proiect a fost redenumit din nou.
Câteva detalii
Producătorul proiectului Classic Shell, Ivo Beltchev, a încetat să mai dezvolte software-ul cu ceva timp în urmă. Dar el a dat codul sursă comunității pentru întreținere ulterioară. Am scris despre asta în cadrul blogului meu german.
Dar ceea ce nu este atât de frumos pentru gustul meu: În momentul de față proiectul produce în prezent doar titluri din cauza multiplelor redenumiri. Pentru o scurtă perioadă de timp, instrumentul s-a numit Classic Start. Apoi, comunitatea a decis să o redenumească la sfârșitul lunii iulie 2018 în NeoClassic-UI/Menu. Poate că există motive întemeiate, nu știu, ele nu au fost niciodată menționate.
Următorul nume nou …
Și acum proiectul a fost redenumit în Open-Shell-Menu. Fișierul actual de instalare se numește acum OpenShellSetup_4_4_4_126.exe, dar probabil că funcționalitatea nu s-a schimbat. Proiectul este disponibil pe GitHub, dar nu toate legăturile sunt încă funcționale. Actuala versiune Nightly Build este disponibilă aici, care expiră după 6 luni.
Latura întunecată a acestui proiect: Securitatea
În afară de „un sac de orez a căzut în China, vă rog să continuați, nimic de văzut”, aș dori să subliniez că ar trebui să vă țineți mâinile departe de acest instrument (cel puțin, până când dezvoltatorii au rezolvat câteva lucruri fundamentale). De ce acest avertisment?
Sunt în contact cu hackerul cu pălărie albă Stefan Kanthak (vezi) de ceva vreme (Microsoft îl înrolează în Top 100 MSRC 2017 și, de asemenea, în alte liste, cum ar fi top 100 Finders în 2015). cercetător în 2015 (vezi).
Stefan Kanthak a postat un comentariu în limba germană, subliniind câteva probleme critice. Iată un scurt extras:
- Pentru comoditate, dezvoltatorii livrează un program de instalare .exe (în loc de un fișier .msi). Acest program de instalare trebuie să fie executat cu privilegii administrative pentru a instala software-ul. Programul de instalare despachetează fișierele necesare într-un director TEMP (neprotejat). Problemă: Dacă există un malware pe sistem care în prezent rulează numai cu drepturile unui cont de utilizator restricționat, capcana este activată.
- Acest malware poate observa procesul de despachetare (există API-uri Windows care pot raporta acest lucru și pot apela o „funcție de agățare” a malware-ului). Apoi este suficient să copieze un fișier DLL cu un anumit nume în folderul TEMP (deoarece acesta este neprotejat, acest lucru este posibil cu drepturi de utilizator limitate).
- În timpul procesului de instalare, programul de instalare încearcă să încarce presupusul DLL Windows, dar accesează DLL-ul plasat de malware datorită caracteristicilor Windows. Iar malware-ul primește prompt drepturi administrative prin intermediul DLL.
Acest lucru este cunoscut de mult timp ca deturnare a ordinului de căutare DLL, un potențial risc de securitate și trebuie evitat cu desăvârșire. Stefan Kanthak a postat câteva link-uri și detalii suplimentare în comentariul său german. Ca o concluzie: Atâta timp cât proiectul nu a abordat aceste probleme, aș evita/fi prudent să folosesc un astfel de software.
Addendum: În acest punct trebuie să mă retrag un pic. Am aruncat o privire la programul de instalare (sub Windows 7). O observație interesantă: Cititorul german Martin Feuerstein a subliniat într-un comentariu, că programul de instalare .exe are un comutator pentru extragerea programelor de instalare .msi – poate fi afișat cu /? Așadar, puteți despacheta fișierul .msi și instala versiunea pe 32-/64 biți prin intermediul programului de instalare .msi.
Există o altă observație: Aparent, programul de instalare .exe rulează în timpul despachetării numai cu drepturi de utilizator standard, despachetează fișierele .msi și îl apelează pe cel corespunzător. Programul de instalare .msi activează solicitarea UAC datorită setărilor din manifestul său și instalează instrumentul. Acest lucru elimină vectorul de atac descris mai sus, conform cunoștințelor mele actuale (dacă msi-ul corect apelează UAC poate fi verificat în promptul UAC). Dacă există noi descoperiri, le voi adăuga.
Adaos 2: Conform lui Stefan Kanthak, programul de instalare ClassicStartSetup_4_4_4_109.exe are următoarele dependențe – pot fi obținute cu:
LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_4_109.exe
COMCTL32.dll
VERSION.dll
KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll
Și DLL-urile de mai sus depind de GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll și
SHLWAPI.dll. Din Windows Vista VERSION.dll nu este un „DLL cunoscut” și orice fișier cu acest nume va fi încărcat din directorul aplicației, dacă este prezent. Același lucru este valabil și pentru SECUR32.dll și RPCRT4.dll.
Nota: În cadrul capturilor de ecran de mai jos și în cadrul comenzii de exemplu, eu folosesc versiunea mai veche ClassicStartSetup_4_4_109.exe. Am efectuat aceleași teste și cu OpenShellSetup_4_4_4_126.exe (cel mai recent nightly build) – același rezultat. De asemenea, nu este disponibilă nicio semnătură digitală. De aceea, las vechile capturi de ecran și comenzi în interiorul textului.
Stefan Kanthak m-a lăsat să folosesc câteva dintre DLL-urile sale de test pentru a rula ClassicStartSetup_4_4_4_109.exe într-un mediu de testare. Iată rezultatul:
(Click to zoom)
O încercare de a afișa opțiunile a avut ca rezultat un avertisment, că un malware ar fi putut manipula fișierele (caseta de dialog din față). După aceea am lăsat programul de instalare .exe să extragă doar instalatorii .msi. Când am executat programul de instalare msi pe 64 de biți, nu s-au mai emis avertismente.
Dar fișierele .msi incluse în fișierul de instalare .exe nu sunt în prezent semnate digital. Motivul: Acestea sunt nightly builds. În acest moment am oprit orice investigație suplimentară. Nightly builds nu sunt pentru sistemele utilizatorilor finali. Să așteptăm, cum arată versiunea finală a acelui instrument și dacă are aceleași vulnerabilități ca cele prezentate mai sus.
Advertising