Theo De Raadta planuje wzmocnienie mechanizmu ochrony pamięci W^X (Write XOR Execute). Istotą mechanizmu jest to, że strony pamięci procesu nie mogą być jednocześnie dostępne do zapisu i wykonania. Zatem wykonanie kodu możliwe jest dopiero po wyłączeniu zapisu, a zapis na stronie pamięci możliwy jest dopiero po wyłączeniu wykonywania. Mechanizm W^X pomaga chronić aplikacje przestrzeni użytkownika przed typowymi atakami związanymi z przepełnieniem bufora, w tym przepełnieniem stosu, i jest aktywny w OpenBSD .
Od początku prac nad W^X było jasne, że to długa droga, gdyż istniała znaczna liczba aplikacji korzystających z JIT. Wdrożenia JIT można podzielić na trzy kategorie:
- Przełączanie pamięci pomiędzy stanami W i X, akceptacja „kosztu” wywołania systemowego .
- Tworzenie aliasów pomiędzy parą mapowań W i X tej samej pamięci.
- Najbardziej „brudna” opcja wymaga modelu pamięci W|X, który umożliwia jednoczesne nagrywanie i wykonywanie.
Obecnie znacznie mniej programów korzysta z trzeciej opcji, a więcej z pierwszej i drugiej. Ponieważ jednak konieczne było uruchamianie programów za pomocą W|X JIT (głównie Chromium i Iridum), dodano opcję montowania systemu plików „wxallowed”, która umożliwiała jednoczesne używanie pamięci zarówno do zapisu, jak i wykonywania, w przypadku, gdy wykonywalny ELF plik oznaczony jest znacznikiem „wxneeded”, a same aplikacje zostały dodatkowo zabezpieczone za pomocą mechanizmów и aby ograniczyć odpowiednio listę używanych wywołań systemowych i części systemu plików dostępnych dla aplikacji.
Aby jeszcze bardziej skomplikować wykorzystywanie luk w takich aplikacjach, zaproponowano dodatek do mechanizmu , który sprawdza, czy wywołanie systemowe jest wykonywane z zapisywalnej strony pamięci. Jeśli strona nadaje się do zapisu, proces jest zmuszony do zakończenia. W ten sposób osoba atakująca nie będzie mogła wykorzystać wywołań systemowych i będzie zmuszona spróbować znaleźć niezbędne gadżety w implementacji JIT lub nawet wykonać trudniejszą pracę polegającą na wykryciu fragmentów wywołań systemowych bezpośrednio w środku .
Procesy Chrome/Iridium są już dość niezawodnie chronione za pomocą zastawu i odsłonięcia, ale usunięcie możliwości użycia na przykład wywołania systemowego write(2) ma oczywiście pewną zaletę, ponieważ stwarza dodatkowe trudności dla atakującego. Jednakże trudności mogą pojawić się również, jeśli implementacja JIT wykorzystuje natywne wywołania systemowe z pamięci W|X. Można jednak mieć nadzieję, że tak się nie stanie, ponieważ ABI było zmieniane kilka razy, ale nikt nigdy nie zgłaszał problemów.
Zmiany są już dostępne w regularnych snapshotach gałęzi OpenBSD-Current, wszystkich zainteresowanych zapraszamy do przetestowania.
Powiązane wieści o pojawieniu się trybu w Chrome/Iridium zasługują na osobny komentarz ze strony Theo . Z jego punktu widzenia jest to dopuszczalne w przypadku niektórych modeli użytkowania, ale prawdopodobnie nie dla wszystkich, ponieważ ten tryb w oczywisty sposób zwiększy obciążenie procesora. Obecnie Chrome będzie działać głównie, jeśli wyłączysz opcję „wxallowed” dla /usr/local, chociaż mogą wystąpić problemy z niektórymi rozszerzeniami (przykładem jest Ghostery). Tak czy inaczej Theo ma nadzieję, że w najbliższej przyszłości pełnoprawna praca w trybie JITless zostanie doprowadzona do stanu w pełni operacyjnego.
Źródło: opennet.ru