Google ujawnia niezałataną lukę w Windowsie 10 – a miała być załatana

James Foreshaw z Google Project Zero odkryłbłąd w mechanizmie Advanced Local Procedure Call (ALPC) –jedna z jego metod pozwala na przypisanie dowolnego deskryptorabezpieczeństwa do dowolnego pliku, pozwalając w konsekwencji napodwyższenie uprawnień działającego kodu do poziomu SYSTEM.

Co ciekawe, inspiracją odkrycia był bardzo podobny błąd w ALPC– jest tam zdalne wywołanie funkcji, która podszywa się podużytkownika, wywołując metodę przeniesienia pliku w nowejmiejsce, a następnie kończy z podszywaniem i próbuje zresetowaćdeskryptor bezpieczeństwa nowego pliku, tak by pasował doodziedziczonych uprawnień. Błąd pozwalający na nadużycie tegomechanizmu został przez Microsoft naprawiony wraz z lutowymiłatkami, ale nie do końca.

Problem pojawia się bowiem gdy wspomnianą funkcję używa siędo przeniesienia hardlinkowanych plików. Windows pozwala nazrobienie hardlinku do pliku, który tylko użytkownik możeodczytać. Jeśli folder zawierający taki hardlink pozwalaużytkownikowi na skasowanie pliku, a zarazem deskryptorbezpieczeństwa pliku na to nie pozwala, to wciąż skasowanie jestmożliwe na bazie uprawnień katalogu – i w konsekwencji ukończenieprzeniesienia pliku jako użytkownik.

Jeśli jednak plik taki zostanie przeniesiony do folderu, któregowpisy kontroli dostępu (ACE) są dziedziczne, dające użytkownikowidostęp, to doprowadzi to do sytuacji, w której odziedziczone ACEzostaną zastosowane na pliku – Windows uzna że jego folderem jestfolder, w którym znajduje się hardlink, a nie folder, w którymplik oryginalnie się znajdował. Można w ten sposób dowolnemuplikowi przypisać dowolny deskryptor bezpieczeństwa, a co za tymidzie pozwolić działającemu ze zwykłymi uprawnieniami kodowi nazmodyfikowanie dowolnego pliku systemowego. Przekonuje o tymprzykładowyexploit, który bezczelnie tworzy plik test.txt w folderzeC:\Windows.

Zgodnie z przedstawionymi w raporcie szczegółami, błądoznaczony jako „1428” został zgłoszony do Microsoftu wlistopadzie zeszłego roku, wraz z analogicznym błędem, oznaczonymjako „1427”. Obu lukom zagwarantowano 90 dni na załatanie – ipodczas ostatniego drugiego wtorku miesiąca Microsoft faktyczniewydał łatkę, eliminującą lukę „1427”. Sęk w tym, żeopisane powyżej „1428” nie zostało załatane, a więc Googlezdecydowało się o zagrożeniu poinformować opinię publiczną.

Oczywiście trzeba pamiętać, że firma z Redmond nie uważa tejluki za krytyczną, ponieważ nie pozwala ona na zdalne uruchomieniekodu, nie jest także możliwe jej wyexploitowanie z przeglądarkizabezpieczonej sandboxem. Wciąż jednak łatwość przeprowadzeniaexploita sugeruje, że twórcy malware szybko sięgną po tętechnikę, uzbrajając swoje rozsyłane jako załączniki pocztyszkodniki w metody podniesienia uprawnień do najwyższego poziomuSYSTEM. Takie malware jest znacznie groźniejsze, ponieważ możeuzyskać stałą obecność w komputerze, nie tylko przetrwaćrestarty, ale też np. zneutralizować oprogramowanie ochronne.

Następne łatanie Windowsa już 13 marca – choć niewykluczone, że jeśli Microsoft uzna ten 0-day za groźny, to wydałatkę poza terminem.