PSA: A Classic Shell mostantól Open Shell menü – és egy figyelmeztetés

Új információ a felhasználók és érdeklődők számára a Windows eszköz Classic Shell: Az utódprojektet máris újra átnevezték, és mostantól Open Shell Menu néven fut. Íme néhány információ és egy tipp, hogy miért mondanám (jelenleg) azt, hogy “óvatosan”.

Van olyan szoftver, amely átnevezéssel tartja magát a figyelem középpontjában. A Classic Shell projektet ebbe a kategóriába sorolnám, mert ezt a projektet ismét átnevezték.

Némi háttér

A Classic Shell fejlesztője, Ivo Beltchev egy ideje abbahagyta a szoftver fejlesztését. A forráskódot azonban átadta a közösségnek további karbantartásra. Erről már blogoltam a német blogom keretein belül.

De ami az én ízlésemnek nem annyira szép: Jelenleg a projekt termel jelenleg csak címszavakat a többszöri átnevezés miatt. Egy rövid ideig az eszköz neve Classic Start volt. Aztán a közösség úgy döntött, hogy 2018 július végén átnevezi NeoClassic-UI/Menu. Talán jó okai vannak, nem tudom, sosem említették őket.

A következő új név …

És most a projektet átkeresztelték Open-Shell-Menu névre. Az aktuális telepítőfájl neve most OpenShellSetup_4_4_126.exe, de a funkcionalitás valószínűleg nem változott. A projekt elérhető a GitHubon, de még nem minden link működik. Az aktuális Nightly Build itt érhető el, amely 6 hónap múlva lejár.

A projekt sötét oldala: A “Kínában felborult egy zsák rizs, kérem folytassa, nincs semmi látnivaló” mellett szeretném felhívni a figyelmet arra, hogy tartsa távol a kezét ettől az eszköztől (legalábbis addig, amíg a fejlesztők nem javítottak ki néhány alapvető dolgot). Miért ez a figyelmeztetés?

Reklám

Egy ideje kapcsolatban állok Stefan Kanthak fehér kalapos hackerrel (lásd) (a Microsoft a Top 100 MSRC 2017-es listáján és más listákon is szerepel, például a Top 100 Finders 2015-ben). kutató 2015-ben (lásd).

Stefan Kanthak írt egy német kommentet, amelyben felvázol néhány kritikus problémát. Íme egy rövid részlet:

• A kényelem érdekében a fejlesztők .exe telepítőt szállítanak (.msi fájl helyett). Ezt a telepítőt rendszergazdai jogosultságokkal kell futtatni a szoftver telepítéséhez. A telepítő kicsomagolja a szükséges fájlokat egy (nem védett) TEMP könyvtárba. Probléma: Ha olyan rosszindulatú szoftver van a rendszerben, amely jelenleg csak egy korlátozott felhasználói fiók jogaival fut, akkor a csapda aktiválódik.
• Ez a rosszindulatú szoftver észreveheti a kicsomagolási folyamatot (vannak Windows API-k, amelyek ezt jelenthetik, és meghívhatják a rosszindulatú szoftver egy “kampófunkcióját”). Ezután elegendő egy bizonyos nevű DLL fájlt a TEMP mappába másolni (mivel ez nem védett, ez korlátozott felhasználói jogokkal lehetséges).
• A telepítési folyamat során a telepítő megpróbálja betölteni a feltételezett Windows DLL-t, de a Windows jellemzői miatt a malware által elhelyezett DLL-hez fér hozzá. A kártevő pedig a DLL-en keresztül azonnal rendszergazdai jogokat kap.

Ez már régóta ismert DLL keresési sorrend eltérítésként, potenciális biztonsági kockázatot jelent, és feltétlenül kerülendő. Stefan Kanthak néhány linket és további részleteket tett közzé német nyelvű hozzászólásában. Következtetésként: Amíg a projekt nem foglalkozik ezekkel a problémákkal, addig én kerülném/óvatos lennék az ilyen szoftverek használatával.

Kiegészítés: Ezen a ponton egy kicsit vissza kell vonulnom. Megnéztem a telepítőt (Windows 7 alatt). Érdekes megfigyelés: Martin Feuerstein német olvasó rámutatott egy kommentben, hogy az .exe telepítőben van egy kapcsoló a .msi telepítők kicsomagolására – megjeleníthető a /? Így az .msi telepítőn keresztül kicsomagolható és telepíthető a 32-/64 bites verzió.

Egy másik megfigyelés is van: Látszólag a .exe telepítő a kicsomagolás során csak normál felhasználói jogokkal fut, kicsomagolja az .msi fájlokat és meghívja a megfelelőt. Az .msi telepítő a manifesztjében lévő beállítások miatt aktiválja az UAC promptot és telepíti az eszközt. Ez kiküszöböli a fent leírt támadási vektort jelenlegi ismereteim szerint (hogy a megfelelő msi hívja-e az UAC-t, azt az UAC promptban lehet ellenőrizni). Ha lesznek új megállapítások, akkor azokat is hozzáadom.

Kiegészítés 2: Stefan Kanthak szerint a ClassicStartSetup_4_4_109.exe telepítőprogramnak a következő függőségek vannak – a következővel szerezhető be:

LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_4_109.exe

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

A fenti DLL-ek pedig a GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll és
SHLWAPI.dll függvényei. Mivel a Windows Vista VERSION.dll nem “ismert DLL”, és minden ilyen nevű fájl betöltődik az alkalmazás könyvtárából, ha van. Ugyanez vonatkozik a SECUR32.dll-re és az RPCRT4.dll-re is.

Megjegyzés: Az alábbi képernyőképeken és a mintaparancson belül a régebbi ClassicStartSetup_4_4_4_109.exe-t használom. Ugyanezeket a teszteket az OpenShellSetup_4_4_4_126.exe (a legfrissebb éjszakai build) segítségével is elvégeztem – ugyanaz az eredmény. Szintén nem áll rendelkezésre digitális aláírás. Ezért hagytam a régi képernyőképeket és parancsokat a szövegben.

Stefan Kanthak megengedte, hogy használjam néhány teszt DLL-jét a ClassicStartSetup_4_4_4_109.exe futtatásához egy tesztkörnyezetben. Íme az eredmény:

(Kattintson a nagyításhoz)

Az opciók megjelenítésére tett kísérlet egy figyelmeztetést eredményezett, miszerint egy malware manipulálhatta a fájlokat (párbeszédpanel elöl). Ezek után hagytam, hogy az .exe telepítő csak kicsomagolja az .msi telepítőket. Amikor a 64 bites msi telepítőt futtattam, több figyelmeztetés nem jelent meg.

De az .exe telepítőfájlban szereplő .msi fájlok jelenleg nincsenek digitálisan aláírva. Az ok: Ezek éjszakai buildek. Ezen a ponton leállítottam a további vizsgálatokat. Az éjszakai buildek nem végfelhasználói rendszerekhez készültek. Várjuk meg, hogyan néz ki az eszköz végleges verziója, és hogy a fentiekben vázolt sebezhetőségekkel rendelkezik-e.