Zemsta Internet Explorera: słabość w obsłudze URI

Konsultanci techniczni z firmy Positive Security opisali podatność umożliwiającą zdalne wykonanie kodu na komputerze ofiary poprzez... kliknięcie linka. Wynika ona ze słabości projektowej obsługi handlera URI z przestrzeni nazw "ms-officecmd:". Jest to błąd charakterystyczny raczej dla oprogramowania z ubiegłego wieku, a jednak pojawia się i dziś.

Windows pozostaje najpopularniejszym systemem operacyjnym dla pecetów nie dlatego, że jest taki świetny, a ze względu na łatwość tworzenia oprogramowania oraz zgodność. Microsoft przez lata gnał na złamanie karku, by dostarczyć rozbudowane narzędzia do tworzenia i uruchamiania oprogramowania na swoich produktach. Niektóre z nich czynią dziś więcej szkody niż pożytku. Chodzi tu o makra Office oraz Internet Explorera.

Przypomnijmy, Internet Explorer to nie jest tylko przeglądarka. Przede wszystkim jest to platforma programistyczna, projektowana pod kątem tworzenia aplikacji o interfejsie użytkownika napisanym w HTML i mechanizmie komunikacji SOAP. Tak pisane aplikacje miałyby mieć możliwość wołać klasyczne funkcje Windows przez COM a także gościć fragmenty kompilowanego kodu wewnątrz siebie (w miarę potrzeby) w formie formantów ActiveX.

Dziś nikt nie pisze aplikacji desktopowych celujących w silnik HTML Internet Explorera, Visual Basic Script przegrał z JS i jest używany już tylko w wirusach, a kontrolki ActiveX słusznie uznano na siłę piekielną i ich obsługa jest zablokowana.

Mniej znanym mechanizmem IE, dziś dostępnym (w o wiele bezpieczniejszej postaci) także w innych przeglądarkach, jest definiowanie niestandardowych przestrzeni nazw. Powłoka Windows umożliwia definiowanie "URI Handlers", adresów innych niż https: oraz file:. Najpopularniejszym z nich jest oczywiście mailto: (poczta), jest jednak mnóstwo innych, jak np. Skype, Zoom czy WebEx. Windows i Office rejestrują kilka handlerów na własne potrzeby. Na przykład ms-settings:/// pozwala przeglądać Ustawienia.

Swój handler rejestruje także Office, by łatwiej powoływać się na inne aplikacje pakietu. Jest nim właśnie ms-officecmd:. Przyjmuje on nie adres, a obiekt, zapisany jako JSON. Jest to lekkie nadużycie mechanizmu, pozostaje jednak "legalne".

Internet Explorer, realizując zrodzone w 1996 roku w Redmond marzenie, wykonuje URI handlery w sposób przezroczysty. Zasoby wskazywane przez nie miały wszak być dostępne na wyciągnięcie ręki, "jak zwykły plik". Dlatego takie dziwadła po kliknięciu w IE (lub aplikacji rysującej coś przez IE, jak HTA) uruchamiają się od razu.

No dobrze, jest to nieroztropne, ale co takiego złego może się stać? Uruchomi się jakiś program pakietu Office? No i co? Niestety, tutaj "nieroztropności" zaczynają się sumować. ms-officecmd: potrafi otworzyć program z parametrem, np. nazwą pliku. To jeszcze nie jest olbrzymi problem (jeżeli plik nie jest złośliwy i nie wykorzystuje dziury). Ale jeżeli wybraną do otwarcia aplikacją jest Teams, wśród parametrów mogą być np. parametry wykonawcze do silnika rysującego.

Teams jest napisany w Electronie. Framework ten zawiera pewną słabość: jeżeli jako "GPU Launcher" podamy do ścieżkę do dowolnego EXE, nawet niebędącego launcherem, Electron uruchomi go, jako proces potomny zaufanej aplikacji Office.

Czytaj też: Speedtest – jak sprawdzić prędkość internetu?

Nowe przeglądarki oparte o Chromium, a także Firefox, przed uruchomieniem niestandardowego URI pytają czy na pewno uruchomić skojarzoną z nim aplikację. Internet Explorer i MSHTML uczynią to tylko, gdy mają wątpliwości. Podobnie jest, gdy parserem ms-officecmd: jest sam Office.

Zabawnym jest, że powodem powstania URI ms-officecmd: jest... Office UWP. Pakiet miał oferować wysoką integrację internetową i w przyszłości zastąpić klasycznego Office'a dla użytkowników indywidualnych. Żadna z tych rzeczy nie miała miejsca, pakiet porzucono, a mimo jego "internetowości", popełniono błąd projektowy właściwy dla ubiegłego stulecia. Odkrywcy podatności informują, że Microsoft załatał lukę w sposób niekompletny i wciąż jest obecna, także w Windows 11.