Kolejny łatkowy wtorek i aktualizacje od Microsoftu. Wśród nich są niespodzianki

Wydane właśnie lutowe aktualizacje, poza naprawą szeregu defektów w niezliczonym tłumie obsługiwanych wersji Windows, naprawiają przede wszystkim luki w zabezpieczeniach. Tym razem adresują one 26 znanych podatności CVE o różnych poziomach ryzyka. Niektórym z nich nie przydzielono jeszcze estymaty CVSS. Oczywiście, część z nich jak zwykle dotyczy komponentu Win32k.

Najmniej niepokojące luki to zawsze te, które wymagają lokalnego dostępu do komputera (ewentualnie uwierzytelnionej sesji zdalnej) i których wykorzystanie pozwala na wyciek danych bez podniesienia uprawnień. Taką słabością jest CVE-2020-0755. Problem znajduje się w Usługach Kryptograficznych i pozwala przewidzieć politykę adresowania obiektów w pamięci. Taka wiedza może potencjalnie ułatwić ataki, które trzeba jednak realizować inną drogą. Dziura znajduje się we wszystkich obsługiwanych wersjach Windows, w tym Windows 7 i 2008 (!). Dokładniej mówiąc, są to sześć dziur: aktualizacja łata również podatności CVE-2020-0756, CVE-2020-0675,CVE-2020-0748, CVE-2020-0676 i CVE-2020-0677, wszystkie podobnej natury. Zapewne odkryte przez tę samą osobę, na fali ostatnich problemów.

Powyższe problemy wyceniono na CVSS 5.5, podobnie jak kolejne luki o podobnym zasięgu, pozwalające na wyciągnięcie alokacji pamięci przy użyciu złośliwej aplikacji (za pomocą lokalnej sesji lub zdalnego wywołania procedury po zalogowaniu). Problemy tego rodzaju zidentyfikowano w mechanizmie zapisywania dzienników (CVE-2020-0658, CLFS, to ostatnio nowa moda), podsystemie GDI (CVE-2020-0744) i usługach Telefonii (CVE-2020-0698, odkryte przez firmę Exatrack)

Kilka nowych luk w jądrze Windows to odkrycie Chińczyków. Również wymagają one zalogowania i pozwalają na wyciek informacji, ale nic ponadto. Dwie z nich dotyczą podsystemu Win32k: chodzi o CVE-2020-0716, oraz CVE-2020-0717 opisane przez Qi'anxin Group. Pierwsza z nich dotyczy systemów Windows w wersjach 8.1 do 1709, a druga – od 1709 do najnowszej. Z kolei Keqi Hu z firmy Qihoo 360 Technology odnalazł podatność CVE-2020-0736 w jądrze w systemach Windows 7, 2008 i 2008 R2. Słabość CVE-2020-0705 w modelu sterownika sieciowego NDIS znaleźli z kolei pracownicy firmy Alibaba. Jest ona obecna we wszystkich wersjach Windows. Bez szwanku nie wyszedł nawet DirectX (CVE-2020-0714), w którym mniejszą dziurę odnalazł Flame陆. Scenariusz czytania pamięci jądra przez użytkownika (CVE-2020-0746) zidentyfikowali pracownicy Qihoo 360.

Wśród lutowych łatek znajdują się dwie podatności, które są warte szczególnej uwagi. Pierwsza z nich jest ważna, bo jest sporą luką, a druga świadczy o rosnącym zainteresowaniu komponentami rzadko pojawiającymi się w raportach bezpieczeństwa.

Dziura CVE-2020-0689 dotyczy komponentu Secure Boot, bardzo ważnego mechanizmu kontroli integralności systemu, obsługiwanego przez systemy Windows 8 i nowsze. Lakoniczny opis wskazuje na to, że menedżer ładowania Windows oferuje rozszerzalność wykorzystywaną przez menedżery firm trzecich. Pozwalają one w niezauważony sposób ładować niezaufany kod i muszą zostać unieważnione. Aktualizacja jest dostarczana oddzielnie, nie wchodzi w skład LCU (latest cumulative update) i wymaga dodatkowego restartu.

Z kolei CVE-2020-0728 to bardzo mała (CVSS 3.3) dziura w komponencie Windows Modules Installer Service (TrustedInstaller.exe). Jest niegroźna, ale pokazuje, że specjalistom powoli udaje się skłonić ten proces do wykonywania nieplanowanych czynności, a działa on z bardzo wysokimi uprawnieniami, wyższymi niż administratorzy.

Windows 7 również otrzymał aktualizacje, na wszystkie powyższe luki (jeżeli go dotyczyły). W przeciwieństwie do Visty kilka lat temu, do której po zakończeniu wsparcia pasowały łatki do Windows Server 2008, instalator aktualizacji odmówi nałożenia jej na system bez klucza MAK uprawnionego do rozszerzonego wsparcia. Nie jest jeszcze jasne, czy możliwe jest nałożenie jej w fazie offline na plik WIM, a następnie zainstalowanie tak załatanego systemu bez klucza. Ale sprawdzimy to. Jednak nawet jeśli to możliwe, potencjalny użytkownik takiej konfiguracji korzystałby ze wsparcia do którego nie jest licencyjnie uprawiony.

Warto skorzystać z okazji i nadmienić, że powyższe zabezpieczenie zostało wprowadzone tak szybko i tak pilnie, że przy okazji popsuto aktywację... Microsoft bardzo nie chce, by ktoś dalej korzystał z Siódemki.