Nové informace pro uživatele a zájemce o nástroj Windows Classic Shell: Navazující projekt byl již znovu přejmenován a nyní se jmenuje Open Shell Menu. Zde je několik informací a nápověda, proč bych (aktuálně) řekl „buďte opatrní“.
Existuje software, který se díky přejmenování udržuje v centru pozornosti. Do této kategorie bych zařadil projekt Classic Shell, protože tento projekt byl opět přejmenován.
Nějaké pozadí
Vývojář Classic Shell, Ivo Beltchev, před časem přestal software vyvíjet. Zdrojový kód však předal komunitě k další údržbě. Psal jsem o tom v rámci svého německého blogu.
Co však na můj vkus není příliš příjemné: V současné době projekt produkují jen titulky kvůli několikanásobnému přejmenování. Krátkou dobu se nástroj jmenoval Classic Start. Pak se komunita rozhodla jej koncem července 2018 přejmenovat na NeoClassic-UI/Menu. Možná k tomu existují dobré důvody, nevím, nikdy nebyly zmíněny.
Další nový název …
A nyní byl projekt přejmenován na Open-Shell-Menu. Aktuální instalační soubor se nyní jmenuje OpenShellSetup_4_4_126.exe, ale funkčnost se pravděpodobně nezměnila. Projekt je k dispozici na GitHubu, ale zatím nejsou funkční všechny odkazy. Aktuální noční sestavení je k dispozici zde, jeho platnost vyprší po 6 měsících.
Temná stránka tohoto projektu: Kromě toho, že „v Číně spadl pytel rýže, prosím pokračujte, nic není vidět“, bych rád upozornil, že byste od tohoto nástroje měli dát ruce pryč (alespoň dokud vývojáři neopraví několik zásadních věcí). Proč toto varování?“
Reklama
S white hat hackerem Stefanem Kanthakem (viz) jsem v kontaktu už delší dobu (Microsoft ho zařadil do žebříčku Top 100 MSRC 2017 a také do dalších seznamů, například Top 100 Finders v roce 2015). Researcher v roce 2015 (viz).
S white hat hackerem Stefanem Kanthakem (viz) jsem v kontaktu už delší dobu (Microsoft ho zařadil do žebříčku Top 100 MSRC 2017 a také do dalších seznamů, například Top 100 Finders v roce 2015). Researcher v roce 2015 (viz).
Stefan Kanthak zveřejnil německý komentář, v němž nastínil některé kritické problémy. Zde je stručný výtah:
- Pro větší pohodlí dodávají vývojáři instalační soubor .exe (místo souboru .msi). Tento instalátor je třeba spustit s právy správce, aby bylo možné software nainstalovat. Instalační program rozbalí požadované soubory do (nechráněného) adresáře TEMP. Problém: Pokud je v systému malware, který se v současné době spouští pouze s právy omezeného uživatelského účtu, aktivuje se past.
- Tento malware si může všimnout procesu rozbalování (existují rozhraní API systému Windows, která to mohou ohlásit a zavolat „hákovou funkci“ malwaru). Pak stačí zkopírovat soubor DLL s určitým názvem do složky TEMP (protože ta není chráněná, je to možné s omezenými uživatelskými právy).
- Při instalačním procesu se instalátor pokusí načíst údajnou knihovnu DLL systému Windows, ale vzhledem k vlastnostem systému Windows přistupuje ke knihovně DLL umístěné malwarem. A malware prostřednictvím DLL okamžitě získá administrátorská práva.
Tento postup je již dlouho znám jako únos pořadí vyhledávání DLL, který představuje potenciální bezpečnostní riziko a je třeba se mu bezpodmínečně vyhnout. Stefan Kanthak ve svém německém komentáři zveřejnil několik odkazů a další podrobnosti. Jako závěr:
Dodatek: Dokud projekt tyto problémy neřešil, používání takového softwaru bych se vyhýbal/byl opatrný: Na tomto místě se musím trochu stáhnout. Podíval jsem se na instalační program (pod Windows 7). Zajímavý postřeh: Německý čtenář Martin Feuerstein v komentáři upozornil, že instalační soubor .exe má přepínač pro extrakci instalačních souborů .msi – lze zobrazit pomocí /? Takže můžete rozbalit .msi a nainstalovat 32-/64bitovou verzi prostřednictvím instalátoru .msi.
Ještě jeden postřeh: Instalační program .exe se zřejmě při rozbalování spustí pouze se standardními uživatelskými právy, rozbalí soubory .msi a zavolá příslušný z nich. Instalátor .msi aktivuje výzvu UAC díky nastavení ve svém manifestu a nainstaluje nástroj. Tím se podle mých současných znalostí eliminuje výše popsaný vektor útoku (zda správný msi volá UAC, lze zkontrolovat ve výzvě UAC). Pokud se objeví nové poznatky, doplním je.
Dodatek 2: Podle Stefana Kanthaka má instalátor ClassicStartSetup_4_4_109.exe následující závislosti – lze získat pomocí:
LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe
COMCTL32.dll
VERSION.dll
KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll
A výše uvedené soubory DLL závisí na souborech GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll a
SHLWAPI.dll. Od systému Windows Vista VERSION.dll není „známou knihovnou DLL“ a jakýkoli soubor s tímto názvem bude načten z adresáře aplikace, pokud je přítomen. Totéž platí pro SECUR32.dll a RPCRT4.dll.
Poznámka: V rámci níže uvedených snímků obrazovky a v rámci ukázkového příkazu používám starší ClassicStartSetup_4_4_109.exe. Stejné testy jsem provedl také s OpenShellSetup_4_4_126.exe (nejnovější noční sestavení) – stejný výsledek. Také není k dispozici žádný digitální podpis. Proto jsem v textu nechal staré screenshoty a příkazy.
Stefan Kanthak mi umožnil použít některé své testovací DLL ke spuštění ClassicStartSetup_4_4_109.exe v testovacím prostředí. Zde je výsledek:
(Klikněte pro zvětšení)
Pokus o zobrazení možností vedl k varování, že se soubory mohl manipulovat škodlivý software (dialogové okno vpředu). Poté jsem nechal instalátor .exe pouze rozbalit instalační soubory .msi. Když jsem spustil 64bitový instalační soubor msi, žádná další varování se již nevydávají.
Soubory .msi obsažené v instalačním souboru .exe však v současné době nejsou digitálně podepsané. Důvod: Jedná se o noční sestavení. V tomto okamžiku jsem další zkoumání zastavil. Noční sestavení nejsou určena pro systémy koncových uživatelů. Počkejme si, jak bude vypadat finální verze tohoto nástroje a zda bude mít stejné zranitelnosti, jaké byly nastíněny výše.
Advertising