No i w końcu stało się. Windows Vista będzie posiadał magiczną technologię określaną jako ASLR. W końcu.
Windows Vista będzie miało ASLR.
Tak naprawdę, to ja nie wiem, czy Windows Vista w końcu taką funkcję posiadać będzie, czy też nie. Ale według informacji zawartych tutaj "funkcja" ta pojawiła się w wersji Beta 2. O co chodzi z ASLR? Ogólnie chodzi o to, by wszystkie systemy nie były monokulturą w zakresie tego co pod jakim adresem pamięci się znajduje. Jeśli w kodzie pojawi się błąd typu buffer overflow pozwala on często na wykonanie dowolnego kodu w systemie. Aby w rzeczywistości ten błąd wykorzystać, trzeba sobie dobrze "utrafić" w miejsce w pamięci ze swoim kodem, tak, by exploit zadziałał zgodnie z oczekiwaniami. W przypadku Windows jest to stosunkowo proste, bo w większości przypadków te same rzeczy będą w tym samym miejscu w pamięci. W przypadku systemu Linux z odpowiednimi łatkami (na przykład PaX) skonstruowanie exploita jest trudniejsze, ponieważ przy każdym uruchomieniu programu jego układ w pamięci jest inny. W przypadku Windows raz napisany exploit działał zawsze. No, przynajmniej w obrębie jednej wersji systemu (z dokładnością do wersji pakietu Service Pack), ewentualnie w grę czasami wchodziła jeszcze wersja językowa. Efekt? Wystarczy przypomnieć sobie czasy takich paskudztw jak Blaster lub Sasser. Warto przy okazji wspomnieć, że systemy typu *nix od dawna posiadają ochronę przed błędami typu buffer overflow. W przypadku OpenBSD jest to technologia W^X, w przypadku Linuxa na przykład łatki na jądro z Grsecurity. W SP2 dla Windows XP i SP1 dla Windows 2003 Microsoft wprowadził technologię DEP, która miała spełniać podobną rolę jak rozwiązania wymienione wcześniej. Niestety, do pełnego wykorzystania DEP potrzebny jest procesor, który rozumie bit NX, co w chwili ukazania się SP2 dla Windows XP nie było zbyt powszechne. Teraz jest już nieco lepiej, ale z tego co udało mi się zaobserwować, to po pierwsze dostawcy sprzętu często wyłączają funkcję NX w BIOS i trzeba ją aktywować ręcznie, a po drugie w domyślnej konfiguracji Windows (nawet po SP2) DEP nie jest aktywny dla wszystkich procesów w systemie, przez co nie może skutecznie chronić przed błędami buffer overflow w aplikacjach uruchamianych przez użytkownika. A szkoda, bo większość exploitów związanych z błędami buffer overflow DEP skutecznie powstrzymywał. Choć Microsoft dopiero teraz wprowadza ASLR do systemu już wcześniej można było z niej skorzystać za pomocą rozwiązań firm trzecich. Wystarczy wspomnieć o porcie PaX dla Windows pod nazwą StackDefender, jest również dostępna (za darmo) implementacja PaX firmy Wehnus. Z drugim produktem zapoznałem się nieco bliżej i nawet sprawdzał się (specjalnie sprawdzałem na przykład exploit na dziurę w obsłudze WMF), ale niestety, powodował BSOD w powiązaniu z moim sterownikiem do modemu w lapotpie...
Ogólnie trzeba przyznać, że Microsoft robi sporo dla podniesienia bezpieczeństwa swojego systemu. Może nie jest odkrywczy, bo PaX był przed DEP, Windows nie będzie również pierwszym systemem implementującym ASLR, ale może niech najpierw zaimplementuje to, co inni już mają od dawna...
Często pomija się również fakt, że bezpieczeństwo wynikowego programu zależy nie tylko od jakości kodu, ale również od... kompilatora jakim zostanie on skompilowany. Albo inaczej - niektóre kompilatory potrafią powodować, że błędy programistów z potencjalnego wykonania kodu zmieniają się w błędy typu DoS. Już od pewnego czasu takie funkcje wbudowane są w Visual Studio, można przeczytać o tym choćby tutaj. Ale taki "security aware" kompilator także nie jest wynalazkiem Microsoftu. Wystarczy wspomnieć choćby o projekcie Hardened Gentoo i hardened toolchain w ramach którego GCC wzbogacany jest o kilka łatek związanych z PaX.
Swoją drogą to ciekawe, czy Microsoft sięga tak głęboko pod maskę, jak choćby OpenBSD reimplementując działanie malloc. A to przypomina mi po raz kolejny, że w wolnej chwili muszę sobie zainstalować OpenBSD 3.9.
