Niektóre podatności w Windows nie wynikają z pojedynczego błędu w kodzie, ale z połączenia kilku pozornie niezależnych mechanizmów systemu. Najnowszy przykład przez Google Project Zero pokazuje, jak niekompletna rejestracja obiektu COM, możliwość zapisu w określonej lokalizacji oraz mechanizm niestandardowego marshalingu mogą wspólnie stworzyć ścieżkę prowadzącą do eskalacji uprawnień. Problem został oznaczony jako CVE-2026-66804 i stanowi jednocześnie niepełną poprawkę wcześniejszej podatności CVE-2026-50343, określanej przez badaczy jako „Dark Elevator”.
Artykuł Jamesa Forshawa z Project Zero jest szczególnie interesujący, ponieważ pokazuje nie tyle pojedynczy błąd, ile sposób myślenia wykorzystywany podczas analizy powierzchni ataku Windows. Kluczowym elementem okazał się tzw. dangling COM registration – wpis wskazujący na komponent DLL, który w rzeczywistości nie istnieje. W odpowiednich warunkach taki „martwy” wpis może zostać wykorzystany do załadowania kontrolowanego przez atakującego kodu do procesu działającego z wysokimi uprawnieniami.
COM jako element powierzchni ataku Windows
COM, czyli Component Object Model, jest jednym z fundamentalnych mechanizmów Windows. Pozwala aplikacjom i usługom korzystać z komponentów udostępniających określone interfejsy, niezależnie od tego, w jakim procesie są one uruchomione. Rejestr systemowy zawiera informacje pozwalające odnaleźć odpowiednią klasę COM, a następnie powiązać ją z konkretnym serwerem – często biblioteką DLL. W analizowanym przypadku problem dotyczył klasy CrossDevice COM, identyfikowanej przez CLSID {E9F83CF2-E0C0-4CA7-AF01-E90C70BEF496}. Rejestr systemowy zawierał informację o tym, iż komponent powinien znajdować się pod ścieżką
%PROGRAMDATA%\CrossDevice\CrossDevice.Streaming.Source.dll.Tyle iż wskazana biblioteka nie istniała.
Sama obecność nieaktualnego wpisu COM nie musi jeszcze oznaczać podatności. W tym przypadku znaczenie miało jednak również miejsce, w którym system spodziewał się znaleźć bibliotekę. C:\ProgramData jest lokalizacją wykorzystywaną przez różne aplikacje i komponenty Windows, a jej podkatalogi mogą być tworzone przez użytkowników. Oznaczało to możliwość przygotowania odpowiedniej struktury katalogów i umieszczenia tam własnej biblioteki DLL.
W efekcie powstał interesujący schemat: system ufał rejestracji komponentu, ale plik, na który wskazywała rejestracja, nie był dostarczony przez system. o ile atakujący może utworzyć plik w oczekiwanej lokalizacji, potencjalnie jest w stanie doprowadzić do załadowania własnego kodu.
Problem zaczyna się od marshalingu
Najciekawsza część analizy Project Zero dotyczy jednak mechanizmu COM marshaling. Jest on wykorzystywany, gdy obiekt COM musi być przekazany pomiędzy procesami. Zamiast przekazywać bezpośrednio obiekt znajdujący się w pamięci jednego procesu, system tworzy reprezentację umożliwiającą jego wykorzystanie po drugiej stronie granicy procesu.
Standardowy mechanizm wykorzystuje tzw. OBJREF, który zawiera informacje potrzebne do nawiązania komunikacji z obiektem. COM obsługuje jednak również bardziej zaawansowany mechanizm – custom marshaling. Obiekt implementujący interfejs IMarshal może wpływać na sposób, w jaki zostanie odtworzony w procesie docelowym.
To właśnie tutaj pojawia się możliwość wykorzystania wcześniejszego, „wiszącego” wpisu COM. Badacz pokazał, iż można skonstruować reprezentację obiektu, która wskazuje jako klasę używaną podczas unmarshalingu właśnie podatny wpis CrossDevice.
Mechanizm jest niebezpieczny z jednego podstawowego powodu – podczas odtwarzania takiego obiektu system musi odnaleźć wskazaną klasę COM, a następnie może próbować załadować powiązaną bibliotekę DLL. o ile biblioteka znajduje się w miejscu, w którym atakujący może ją wcześniej umieścić, powstaje możliwość wykonania kontrolowanego przez niego kodu.
Nie wystarczyło jednak samo znalezienie podatnego wpisu. Kod musi zostać załadowany do procesu posiadającego odpowiednio wysokie uprawnienia.
SYSTEM po drugiej stronie granicy
Windows od lat posiada mechanizmy mające ograniczać ryzyko związane z custom marshalingiem. Microsoft wprowadził m.in. możliwość blokowania niestandardowego unmarshalingu poprzez odpowiednie ustawienia COM. Wśród nich znajduje się flaga EOAC_NO_CUSTOM_MARSHAL, a także mechanizm COMGLB_UNMARSHALING_POLICY, mogący wymuszać silniejszą politykę bezpieczeństwa.
W związku z tym kluczowym etapem badań było znalezienie uprzywilejowanego komponentu COM, który działa jako SYSTEM, a jednocześnie pozwala na wykorzystanie custom marshalingu.
Project Zero wskazał tutaj interesujący komponent, nazwany Shell Create Object Handler. Jest on uruchamiany w kontekście NT AUTHORITY\SYSTEM, ale jego aktywacja nie odbywa się w standardowy sposób. Badacz odkrył, iż odpowiedni proces może zostać uruchomiony poprzez zadanie harmonogramu Windows \Microsoft\Windows\Shell\CreateObjectTask.
To kolejny istotny element całego łańcucha. Sam fakt istnienia procesu działającego jako SYSTEM nie byłby wystarczający. Istotne, iż mechanizm uruchomienia komponentu był dostępny z poziomu zwykłego użytkownika, a następnie proces nie blokował custom marshalingu.
W rezultacie powstał łańcuch obejmujący kilka elementów:
użytkownik → dostępny komponent COM → proces SYSTEM → custom marshaling → dangling COM registration → kontrolowana biblioteka DLL.
Właśnie kombinacja tych mechanizmów pozwalała przejść od stosunkowo niewinnego błędu w konfiguracji do wykonania kodu z wysokimi uprawnieniami.
Dlaczego nie jest to „zwykła” podatność DLL hijacking?
Na pierwszy rzut oka można by uznać, iż mamy tutaj do czynienia z klasycznym DLL hijackingiem. To jednak zbyt duże uproszczenie.
W typowym scenariuszu DLL hijackingu aplikacja poszukuje biblioteki w określonych lokalizacjach, a atakujący wykorzystuje niewłaściwą kolejność wyszukiwania lub zapisywalny katalog. W przypadku opisanym przez Project Zero istotny jest natomiast łańcuch zaufania COM.
Windows posiada w rejestrze informację mówiącą, gdzie znajduje się określony komponent. Następnie COM wykorzystuje ją podczas unmarshalingu obiektu. Atakujący nie musi więc „przekonać” przypadkowej aplikacji do uruchomienia swojej biblioteki. Musi doprowadzić do sytuacji, w której systemowy mechanizm COM sam uzna ją za adekwatny serwer dla określonej klasy.
Pokazuje to szerszy problem związany z bezpieczeństwem Windows – nieaktualne lub osierocone wpisy rejestru mogą być czymś więcej niż tylko bałaganem administracyjnym. o ile dotyczą komponentów COM i wskazują na lokalizacje, do których zwykły użytkownik ma możliwość zapisu, powinny być traktowane jako potencjalny element powierzchni ataku.
„Niepełna poprawka” jest często ważniejsza niż pojedynczy błąd
CVE-2026-66804 jest frapujące również dlatego, iż według Project Zero było związane z wcześniejszym problemem CVE-2026-50343. Pierwsza ścieżka wykorzystująca podatny komponent została usunięta, ale sama problematyczna rejestracja COM pozostała.
To klasyczny problem w przypadku skomplikowanych mechanizmów systemowych. Usunięcie jednej ścieżki eksploatacji nie musi oznaczać usunięcia pierwotnej przyczyny. o ile przez cały czas istnieje możliwość osiągnięcia tego samego niebezpiecznego stanu innym mechanizmem, badacz może znaleźć nowy sposób wykorzystania podatności.
W tym przypadku wcześniejszy sposób wykorzystania CrossDevice COM został zablokowany, ale Forshaw poszukał alternatywnego mechanizmu dostarczenia obiektu do uprzywilejowanego procesu. Ostatecznie wykorzystał do tego custom marshaling. Jest to cenna lekcja również dla osób odpowiedzialnych za bezpieczeństwo przedsiębiorstw: analiza poprawki nie powinna ograniczać się do sprawdzenia, czy konkretny exploit przestał działać. Ważne jest ustalenie, czy usunięto przyczynę problemu, czy tylko konkretną drogę prowadzącą do jej wykorzystania.
Jak szukać podobnych problemów?
Jednym z ciekawszych elementów publikacji jest próba automatycznego wyszukiwania kolejnych „dangling COM registrations”. Forshaw wskazuje, iż można przeszukiwać bazę klas COM i identyfikować komponenty typu InProcServer32, dla których wskazany plik DLL nie może zostać odnaleziony.
Nie każdy taki wpis jest oczywiście równoznaczny z podatnością. najważniejsze powinno być ustalenie kilku dodatkowych parametrów: gdzie znajduje się oczekiwana biblioteka, kto może zapisywać w danej lokalizacji oraz jaki proces może próbować załadować komponent.
Szczególnie interesujące są przypadki, w których ścieżka prowadzi do katalogów znajdujących się w obszarach współdzielonych lub potencjalnie zapisywalnych przez zwykłych użytkowników. W środowisku korporacyjnym warto więc patrzeć na COM nie tylko jako mechanizm kompatybilności aplikacji, ale również element infrastruktury bezpieczeństwa systemu operacyjnego.
Co ta historia mówi o bezpieczeństwie Windows?
Opis Project Zero pokazuje, iż współczesne eskalacje uprawnień w Windows mogą wymagać połączenia kilku mechanizmów, które pojedynczo nie muszą wyglądać groźnie. Osierocony wpis COM, zapisywalny katalog, niestandardowy marshaling oraz uprzywilejowany proces dają razem zupełnie inną sytuację niż każdy z tych elementów analizowany osobno. To również dobry przykład tego, dlaczego mechanizmy takie jak COM, DCOM, RPC czy scheduled tasks pozostają interesującym obszarem badań bezpieczeństwa. Są głęboko zintegrowane z systemem operacyjnym i często funkcjonują na granicy różnych poziomów zaufania.
Z perspektywy administratorów najważniejszym działaniem jest oczywiście wdrożenie poprawek Microsoft dotyczących CVE-2026-66804 oraz wcześniejszej podatności CVE-2026-50343. Warto również monitorować nietypowe ładowanie bibliotek DLL przez procesy działające jako SYSTEM, analizować nietypowe aktywacje COM oraz zwracać uwagę na biblioteki ładowane z lokalizacji, które mogą być modyfikowane przez mniej uprzywilejowanych użytkowników. Historia CrossDevice pokazuje przy tym coś jeszcze – w Windows „martwy” wpis w rejestrze nie zawsze oznacza martwy problem. Czasami właśnie taki brakujący element jest tym, co pozwala atakującemu wstawić własny komponent w miejsce oczekiwanego przez system.
Google Project Zero po raz kolejny pokazuje więc, iż w bezpieczeństwie Windows szczególnie groźne bywają nie pojedyncze błędy, ale zależności pomiędzy mechanizmami. W tym przypadku drogę do uprawnień SYSTEM otworzył niepozorny wpis COM wskazujący na bibliotekę DLL, której fizycznie nie było.
