r   e   k   l   a   m   a
reklama

Windows 8 zepsuło randomizację pamięci (ASLR) Microsoftu: czekamy na ataki re-use

Strona główna Aktualności

O autorze

Hodowca maszyn wirtualnych i psów, poza tym stary linuksiarz, bonvivant i śmieszek. W 2012 roku napisał na DP o algorytmie haszowania Keccak i wciąż pamięta, jak on działa.

Will Dormann, pracujący w ośrodku CERT uniwersytetu Carnegie-Mellon, przyglądał się poprawionemu podczas ostatnich wtorkowych aktualizacji przez Microsoft edytorowi równań. Przyglądając się mu, odkrył przy okazji w Windowsie ciekawy błąd, związany z mechanizmem randomizacji przestrzeni adresowej (ASLR) – jednym z najważniejszych zabezpieczeń przed exploitami podatności wynikających z popsucia pamięci.

Użytkownicy Windowsa 7 mogą spać spokojnie. Jednak we wszystkich nowszych systemach Microsoftu, poczynając od Windowsa 8, zmieniono implementację ogólnosystemowego ASLR. Aby obowiązkowy ASLR otrzymał entropię z puli systemu, to włączony musi być ogólnosystemowy ASLR typu bottom-up. Narzędzia włączające ogólnosystemowy ASLR bez jednoczesnego ustawienia ASLR typu bottom-up, nie zapewnią odpowiedniej losowości dla aplikacji, które dobrowolnie włączają ASLR.

Konieczne jest tutaj wyjaśnienie. Obowiązkowe ASRL w Windowsie zmienia jedynie podstawowy adres aplikacji, który pozostaje niezmienny do restartu maszyny. Napastnik może wykorzystać to do stworzenia exploita, który ponownie wykorzysta odkryte lokacje dla tych aplikacji, które były wielokrotnie uruchamiane w czasie jednego cyklu pracy maszyny.

Tymczasem ASLR typu bottom-up zwiększa entropię obowiązkowego ASLR, zmienia bazowy adres chronionych aplikacji za każdym razem, gdy są one uruchamiane.

Co więc się dzieje z takim edytorem równań eqnedt32.exe? W Windowsie 7, z włączonymi rozszerzeniami EMET, za każdym restartem maszyny znajdzie się on pod innym adresem w pamięci. Tymczasem w Windowsie 10 (oraz 8.1), bez względu na stan EMET czy też nowego Windows Defender Exploit Guard (WDEG), za każdym razem eqnedt32.exe pojawia się w tym samym miejscu pamięci. Windows 10 po prostu nie stosuje ASLR dla tej aplikacji!

Dotknięte tym błędem są wszystkie aplikacje, które stosują obowiązkowy ASLR. Problem nie dotyczy aplikacji, które stosują dobrowolny (opt-in) ASLR.

Skąd ta usterka? W Windowsie 7 i wcześniej ustawienia obowiązkowego ASLR znajdowały się w Rejestrze, w HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages. Po ustawieniu tam wartości 0xFFFFFFFF, Windows 7 automatycznie zadba o to, by kod pojawiał się pod różnymi lokacjami pamięci po restarcie maszyny.

Od Windowsa 8 obowiązkowe ASLR jest ustawiane w Rejestrze pod HKLM\System\CurrentControlSet\Control\Session Manager\Kernel\MitigationOptions wartością binarną, ale by działało, jednocześnie włączone być musi ASLR typu bottom-up. To znaczy ono działa, ale po prostu nie dostaje entropii, więc w konsekwencji aplikacja uruchamiana jest zawsze pod tym samym adresem.

Jak się zabezpieczyć?

Odkrywca jak i cały zespół CERT twierdzą, że nie znają obecnie praktycznego rozwiązania tego problemu. Jedyne co można zrobić, to włączyć ogólnosystemowe ASLR typu bottom-up na maszynach, które mają ogólnosystemowe obowiązkowe ASLR. W tym celu należy do Rejestru zaimportować następującą wartość: (plik .REG dostępny na GitHubie)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] "MitigationOptions"=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00

Microsoft nie ustosunkował się jeszcze do całej kwestii. Spodziewajmy się gwałtownego wzrostu liczby ataków typu code re-use na nowsze systemy z rodziny Windows.

© dobreprogramy
reklama
r   e   k   l   a   m   a

Komentarze

reklama
Polecamy w WP TechnologieWP TechnologieNa Facebooku zamówisz hydraulika. Nowość w Marketplace