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

21 listopada 2017, 15:58

Will Dormann, pracujący w ośrodku CERT uniwersytetuCarnegie-Mellon, przyglądał się poprawionemu podczas ostatnichwtorkowych aktualizacji przez Microsoft edytorowirównań. Przyglądając się mu, odkrył przy okazji w Windowsieciekawy błąd, związany z mechanizmem randomizacji przestrzeniadresowej (ASLR) – jednym z najważniejszych zabezpieczeń przedexploitami podatności wynikających z popsucia pamięci.

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

Konieczne jest tutaj wyjaśnienie. Obowiązkowe ASRL w Windowsiezmienia jedynie podstawowy adres aplikacji, który pozostajeniezmienny do restartu maszyny. Napastnik może wykorzystać to dostworzenia exploita, który ponownie wykorzysta odkryte lokacje dlatych aplikacji, które były wielokrotnie uruchamiane w czasiejednego cyklu pracy maszyny.

Tymczasem ASLR typu bottom-up zwiększa entropię obowiązkowegoASLR, 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? WWindowsie 7, z włączonymi rozszerzeniami EMET, za każdym restartemmaszyny znajdzie się on pod innym adresem w pamięci. Tymczasem wWindowsie 10 (oraz 8.1), bez względu na stan EMET czy też nowegoWindows Defender Exploit Guard (WDEG), za każdym razem eqnedt32.exepojawia się w tym samym miejscu pamięci. Windows 10 po prostu niestosuje 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 ustawieniaobowiązkowego ASLR znajdowały się w Rejestrze, wHKLM\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagement\MoveImages. Po ustawieniu tam wartości 0xFFFFFFFF,Windows 7 automatycznie zadba o to, by kod pojawiał się pod różnymilokacjami pamięci po restarcie maszyny.

Actually, with Windows 7 and EMET System-wide ASLR, the loaded address for eqnedt32.exe is different on every reboot. But with Windows 10 with either EMET or WDEG, the base for eqnedt32.exe is 0x10000 EVERY TIME. Conclusion: Win10 cannot be enforce ASLR as well as Win7! pic.twitter.com/Jp10nqk1NQ

— Will Dormann (@wdormann) November 15, 2017Od Windowsa 8 obowiązkowe ASLR jest ustawiane w Rejestrze podHKLM\System\CurrentControlSet\Control\SessionManager\Kernel\MitigationOptions wartością binarną, ale bydział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 wkonsekwencji 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 typubottom-up na maszynach, które mają ogólnosystemowe obowiązkoweASLR. 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 codere-use na nowsze systemy z rodziny Windows.

Adam Golański