Office w tarapatach. Zagrożenie luką 0‑day rośnie

Opisywana przez Oskara podatność w pakiecie Microsoft Office okazuje się być poważniejsza, niż początkowo zakładano. Jej nowe iteracje zaczynają korzystać z wektorów ataku niewykrywanych przez Defendera, a niezastąpiony Kevin Beaumont zlikwidował konieczność wołania kontrolek ActiveX. W ten sposób przejściowe rozwiązanie sugerowane przez Microsoft do czasu opracowania poprawki, przestało działać.

Przypomnijmy: luka znajduje się w komponencie MSHTML, czyli "kontrolce WebView" Internet Explorera, z czasów zanim stosowanie WebView było modne (lub znane). Komponent ten jednak nie może być używany autonomicznie, trzeba go osadzić w aplikacji lub dokumencie OLE. Okazuje się, że jako element osadzony podlega kontroli na prawach "strefy lokalnej". W języku Internet Explorera sprzed dwudziestu lat oznacza to strefę nieskończenie zaufaną.

To niemal ten sam problem, który do dziś zachodzi w składniku MSHTA, innym silniku osadzonym Internet Explorera. Strony internetowe działają w strefie zabezpieczeń "internet", lokalne pliki HTA w strefie, rzecz jasna, lokalnej - ale wymagają ręcznego pobrania. Niestety, sam silnik MSHTA może przyjmować URL jako parametr. W rezultacie uruchamia kod z internetu jako lokalny.

Nowe metody wykorzystania dziury MSHTML stosują właśnie ten ślepy punkt w myśleniu projektantów IE. Makra i "zawartość aktywna" są domyślnie blokowane. Ale ich odblokowanie, ze względu na wady projektowe, nie sprawi że kod z internetu będzie uruchamiany w kontekście zabezpieczeń internetowych. Zamiast tego nie zostaną zastosowane żadne.

A metod skłonienia Worda do uruchamiania kodu z internetu jest sporo. Jedną z nich, stosowaną najwyraźniej od ponad tygodnia (acz istnieją poszlaki, że dzieje się to już nawet od roku), jest oparcie dokumentu o szablon (DOCT) ze wskazaniem jego źródła jako URL w internecie. Word pobiera szablon automatycznie.

MSHTML działający w strefie lokalnej pozwala nie tylko uruchamiać niepodpisane kontrolki ActiveX z internetu ale także wykonywać skrypty VBS. Zastosowanie pliku CAB z ActiveX dostarcza kilka dodatkowych korzyści w kwestii stosowania exploitu, ale da się obyć bez tego. To niejedyny problem.

Przed niezaufanym kodem ma chronić Tryb Odczytu w pakiecie Office. Dopiero wyłączenie go sprawia, że ActiveX może w ogóle działać. Owszem, wyłączenie obsługi ActiveX rozwiązuje problem, ale ryzyko powstaje dopiero w przypadku wyjścia z Trybu Odczytu. I dotyczy wtedy wariantu zarówno z ActiveX jak i bez niego. A zatem zastosowanie reguły "nie bierz cukierków od obcych" powinno wystarczyć.

Niestety, okazuje się, że Tryb Odczytu nie zawsze działa. Miniatura podglądu w oknie systemowego Eksploratora Plików okazuje się wołać kompletnego Worda celem narysowania się i wywołanie to zachodzi bez trybu chronionego. Jest to zaskakująca, jak na 2021, pozostałość po "myśleniu sprzed Service Packa 2 do XP" (czyli w praktyce sprzed Trustworthy Computing).

Prawdziwym rozwiązaniem problemu okazuje się zatem być nie tylko wyłączenie ActiveX oraz makr, ale także wyłączenie panelu podglądu w Eksploratorze (o ile był włączony) oraz zablokowanie forkowania procesów Office za pomocą reguł redukcyjnych Defendera, których zaaplikowanie jest nietrywialne i zależne od licencji. Zablokowanie Internet Explorera na zaporze także nic nie da, bowiem to nie IE, a MSHTML.DLL dokonuje połączenia. Co więcej, ten drugi jest dostępny w systemie nawet po odinstalowaniu IE.

Windows i Office padają ofiarą rozwiązań, które przez wiele lat były siłą pędną ich sprzedaży: środowisk programowania wbudowanych literalnie we wszystko i siłowe zintegrowanie ich z internetem. Kiedyś pozwalało to tworzyć rozbudowane aplikacje zintegrowane z pakietem biurowym i firmową siecią. Dziś stanowi piekło arbitralnego kodu. Windows ma o wiele więcej takich niemożliwych do prędkiego załatania składników. Przed MSHTML był MSHTA. Przed nim Edytor Równań. A jeszcze wcześniej - legendarny WMF, niezałatany przez dobrych kilka tygodni na przełomie lat 2005 i 2006.