Nowe informacje dla użytkowników i osób zainteresowanych narzędziem Windows Classic Shell: Projekt kontynuacji został już ponownie przemianowany i nazywa się teraz Open Shell Menu. Oto kilka informacji i wskazówka, dlaczego (obecnie) powiedziałbym „bądź ostrożny”.
Jest oprogramowanie, które utrzymuje się w centrum uwagi poprzez zmianę nazwy. Sklasyfikowałbym projekt Classic Shell w tej kategorii, ponieważ ten projekt został ponownie przemianowany.
Kilka kontekstów
Twórca Classic Shell, Ivo Beltchev, przestał rozwijać oprogramowanie jakiś czas temu. Ale przekazał kod źródłowy społeczności do dalszego utrzymania. Pisałem o tym na moim niemieckim blogu.
Ale co nie jest tak miłe jak na mój gust: W tej chwili projekt produkuje obecnie tylko nagłówki z powodu wielokrotnej zmiany nazwy. Przez krótki czas narzędzie było nazywane Classic Start. Następnie społeczność zdecydowała się zmienić jego nazwę pod koniec lipca 2018 na NeoClassic-UI/Menu. Być może istnieją dobre powody, nie wiem, nigdy nie zostały wspomniane.
Kolejna nowa nazwa …
A teraz projekt został przemianowany na Open-Shell-Menu. Aktualny plik instalacyjny nazywa się teraz OpenShellSetup_4_4_126.exe, ale funkcjonalność chyba się nie zmieniła. Projekt jest dostępny na GitHubie, ale nie wszystkie linki są jeszcze funkcjonalne. Aktualny Nightly Build jest dostępny tutaj, który wygasa po 6 miesiącach.
Ciemna strona tego projektu: Security
Beside the 'a sack rice fell over in China, please continue, nothing to see’, I would like to point out that you should keep your hands away from this tool (at least, until the developers has fixed a few fundamental things). Dlaczego to ostrzeżenie?
Od jakiegoś czasu jestem w kontakcie z white hat hakerem Stefanem Kanthakiem (zobacz) (Microsoft wpisuje go na listę Top 100 MSRC 2017, a także na inne listy, jak np. Top 100 Finderów w 2015r.) badacz w 2015 roku (zobacz).
Stefan Kanthak zamieścił niemiecki komentarz, w którym nakreślił kilka krytycznych kwestii. Oto krótki fragment:
- Dla wygody, deweloperzy dostarczają instalator .exe (zamiast pliku .msi). Ten instalator musi być uruchomiony z uprawnieniami administracyjnymi, aby zainstalować oprogramowanie. Instalator rozpakowuje wymagane pliki do (niezabezpieczonego) katalogu TEMP. Problem: Jeśli w systemie znajduje się złośliwe oprogramowanie, które obecnie działa tylko z uprawnieniami konta użytkownika z ograniczeniami, pułapka jest aktywna.
- To złośliwe oprogramowanie może zauważyć proces rozpakowywania (istnieją interfejsy API Windows, które mogą to zgłosić i wywołać „funkcję haka” złośliwego oprogramowania). Następnie wystarczy skopiować plik DLL o określonej nazwie do folderu TEMP (ponieważ jest on niezabezpieczony, jest to możliwe przy ograniczonych prawach użytkownika).
- Podczas procesu instalacji instalator próbuje załadować rzekomą bibliotekę DLL systemu Windows, ale ze względu na właściwości systemu Windows uzyskuje dostęp do DLL umieszczonej przez malware. A złośliwe oprogramowanie natychmiast otrzymuje prawa administracyjne poprzez DLL.
To jest znane od dawna jako DLL search order hijacking, potencjalne zagrożenie bezpieczeństwa i powinno być absolutnie unikane. Stefan Kanthak zamieścił kilka linków i dalszych szczegółów w swoim niemieckim komentarzu. Jako podsumowanie: Tak długo jak projekt nie zajął się tymi kwestiami, unikałbym/byłbym ostrożny używając takiego oprogramowania.
Dodatek: W tym momencie muszę się trochę wycofać. Rzuciłem okiem na instalator (pod Windows 7). Ciekawe spostrzeżenie: Niemiecki czytelnik Martin Feuerstein zwrócił uwagę w komentarzu, że instalator .exe ma przełącznik do rozpakowywania instalatorów .msi – można go wyświetlić za pomocą /? Można więc rozpakować .msi i zainstalować wersję 32-/64-bitową za pomocą instalatora .msi.
Jest jeszcze jedno spostrzeżenie: Najwyraźniej instalator .exe uruchamia się podczas rozpakowywania tylko ze standardowymi prawami użytkownika, rozpakowuje pliki .msi i wywołuje odpowiedni z nich. Instalator .msi aktywuje monit UAC dzięki ustawieniom w swoim manifeście i instaluje narzędzie. To eliminuje wektor ataku opisany powyżej zgodnie z moją obecną wiedzą (czy właściwy msi wywołuje UAC można sprawdzić w podpowiedzi UAC). Jeśli pojawią się nowe odkrycia, dodam je.
Uzupełnienie 2: Według Stefana Kanthaka instalator ClassicStartSetup_4_4_109.exe ma następujące zależności – można je uzyskać za pomocą:
LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe
COMCTL32.dll
VERSION.dll
KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll
And the above DLLs depends on GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll and
SHLWAPI.dll. Od Windows Vista VERSION.dll nie jest „znaną biblioteką DLL” i każdy plik o tej nazwie zostanie załadowany z katalogu aplikacji, jeśli jest w nim obecny. To samo dotyczy SECUR32.dll i RPCRT4.dll.
Uwaga: W poniższych zrzutach ekranu i w przykładowym poleceniu, używam starszego ClassicStartSetup_4_4_109.exe. Te same testy przeprowadziłem również z OpenShellSetup_4_4_126.exe (najnowsza wersja nightly build) – ten sam rezultat. Również brak podpisu cyfrowego. Dlatego pozwalam sobie na stare zrzuty ekranu i komendy w tekście.
Stefan Kanthak pozwolił mi użyć niektórych z jego testowych DLL do uruchomienia ClassicStartSetup_4_4_109.exe w środowisku testowym. Oto wynik:
(Kliknij, aby powiększyć)
Próba wyświetlenia opcji zakończyła się ostrzeżeniem, że złośliwe oprogramowanie mogło manipulować plikami (okno dialogowe z przodu). Następnie pozwoliłem instalatorowi .exe po prostu rozpakować instalatory .msi. Kiedy uruchomiłem 64-bitowy instalator msi, nie pojawiło się więcej ostrzeżeń.
Ale pliki .msi zawarte w pliku instalatora .exe nie są obecnie podpisane cyfrowo. Powód: Są to nocne kompilacje. W tym momencie zaprzestałem dalszych poszukiwań. Nocne kompilacje nie są przeznaczone dla systemów użytkowników końcowych. Poczekajmy, jak będzie wyglądała finalna wersja tego narzędzia i czy posiada ona te same luki, które opisałem powyżej.
Advertising