Theo De Raadt planami wzmocnienia mechanizmu ochrony pamięci W^X (Write XOR Execute). Istota mechanizmu polega na tym, że strony pamięci procesu nie mogą być jednocześnie dostępne do zapisu i wykonania. W ten sposób, kod może być wykonany tylko po zablokowaniu zapisu, a zapis do strony pamięci jest możliwy tylko po zakazaniu wykonania. Mechanizm W^X pomaga chronić aplikacje w przestrzeni użytkownika przed typowymi atakami, przeprowadzanymi za pomocą przepełnienia bufora, w tym przed przepełnieniami stosu i jest aktywny w OpenBSD .
Od początku prac nad W^X było jasne, że to długa droga, ponieważ istnieje znaczna liczba aplikacji korzystających z JIT. Realizacje JIT można podzielić na trzy kategorie:
- Przełączanie pamięci między stanami W i X, godząc się z „kosztem” wywołania systemowego .
- Tworzące aliasy między parą W i X odwzorowań tej samej pamięci.
- Najbardziej „brudna” opcja - wymaga modeli pamięci W|X, które pozwalają na jednoczesne zapisywanie i wykonanie.
Obecnie znacznie mniej programów korzysta z trzeciej opcji i więcej z pierwszej i drugiej. Niemniej jednak, ponieważ konieczne było uruchamianie programów z W|X JIT (głównie Chromium i Iridum), dodano opcję montowania systemu plików „wxallowed”, która pozwalała na wykorzystanie pamięci zarówno do zapisu, jak i wykonywania, jeśli wykonywalny plik ELF był oznaczony znacznikiem „wxneeded”, a same aplikacje były dodatkowo zabezpieczane przy użyciu mechanizmów. i w celu ograniczenia listy używanych wywołań systemowych oraz dostępnych dla aplikacji części systemu plików.
Aby dodatkowo utrudnić wykorzystanie luk w bezpieczeństwie w podobnych aplikacjach, zaproponowano rozszerzenie mechanizmu , które sprawdza, czy wywołanie systemowe jest wykonywane z dostępnej do zapisu strony pamięci. Jeśli strona jest dostępna do zapisu, proces jest wymuszona zakończenia. W ten sposób, napastnik nie będzie mógł używać wywołań systemowych i będzie zmuszony próbować znaleźć odpowiednie gadgety w realizacji JIT lub nawet wykonać trudniejszą pracę polegającą na odkrywaniu zastępczych wywołań systemowych bezpośrednio w .
Procesy Chrome/Iridium są już dość solidnie chronione za pomocą pledge i unveil, ale odebranie możliwości korzystania, na przykład, z systemowego wywołania write(2) ma oczywiście pewne zalety, ponieważ stwarza atakującemu dodatkowe trudności. Niemniej jednak trudności mogą się pojawić, jeśli implementacja JIT korzysta z natywnych wywołań systemowych z pamięci W|X. Można jednak mieć nadzieję, że nie będzie to konieczne, ponieważ ABI wielokrotnie się zmieniało, ale nikt nigdy nie zgłaszał problemów.
Zmiany są już dostępne w regularnych snapshotach gałęzi OpenBSD-CURRENT, wszyscy zainteresowani są zaproszeni do testowania.
Osobny komentarz ze strony Theo zasługują powiązane wiadomości o pojawieniu się w Chrome/Iridium trybu . Z jego punktu widzenia jest to akceptowalne dla niektórych modeli użycia, jednak prawdopodobnie nie dla wszystkich, ponieważ w tym trybie oczywiście wzrośnie obciążenie procesora. Obecnie Chrome głównie działa, jeśli wyłączy się „wxallowed” dla /usr/local, chociaż mogą wystąpić problemy z niektórymi rozszerzeniami (jako przykład podaje się ghostery). Tak czy inaczej, Theo ma nadzieję, że pełne działanie w trybie JITless zostanie doprowadzone do stanu roboczego w najbliższym czasie.
Źródło: opennet.ru
