Niebezpiecznik

Można ograniczać możliwość zadziałania RCE (oraz innych exploitów), ale samo to przy odpowiednio zdeterminowanym atakującym dysponującym odpowiednią ilością czasu oraz pieniędzy może nie wystarczyć – trzeba też zająć się ograniczeniem skutków ewentualnego zadziałania szkodliwego kodu. Podam kilka przykładów dla tych dwóch mechanizmów (często współdziałające ze sobą – np. utwardzony kernel zablokuje część ewentualnych RCE oraz sporo innych exploitów, ale może też znacznie utrudnić ucieczkę z sandboxa).

Linux:
Aktualne oprogramowanie będące pierwszą linią obrony (zwykły użytkownik nie ma się zbytnio co obawiać ataku przez exploit 0-day). 1 lub 2 komendy i załatwione.

“Na wszelki wypadek” podobnych luk w przyszłości można zamknąć “wrażliwą oraz wystawioną na ataki” aplikację w jakiejś piaskownicy (lub nawet i 2 w 1 – uruchomić w piaskownicy na maszynie wirtualnej. Istnieje większa szansa, że jak coś ucieknie z sandboxa, to zatrzyma się na maszynie wirtualnej, bo luki pozwalające na ucieczkę z maszyny wirtualnej są “cenniejsze” i nie rzuca się takim kalibrem exploitów na lewo i prawo).

Sandboxować też “trzeba umieć” – wyciąć dostęp do pulseaudio dla sandboxa oraz używać Waylanda zamiast X-ów (exploitowanie przez sockety w X-ach to rzecz, której nie da się skutecznie zatrzymać – albo X-y, albo szczelny sandboxing. Nie ma niczego pomiędzy. ). Postawiłbym tu na prostotę – “bubblewrap” w trybie “suid-helpera” (łatwe do zaudytowania i ogarnięcia kilkaset linii kodu + łatwy i dobrze znany mechanizm działania – “powierzchnia ataku” jest znacznie mniejsza niż w kompleksowych rozwiązaniach typu “firejail”) oraz filtrowanie syscalli, które mogą zostać użyte do ucieczki z takiego odizolowanego środowiska (“zbędne syscalle” można wyciąć używając Seccomp oraz Seccomp-bpf).

Do tego można użyć utwardzonej wersji kernela dostępnej w wielu dystrybucjach i dodatkowo wyłączyć potencjalnie exploitogenne (lub ułatwiające inne próby exploitowania) rzeczy (typu wyłączenie “clone newuser” dla nieuprawnionych użytkowników, wyłączenie dostępu do dmesg dla nieuprawnionych użytkowników, wyłączenie “unprivileged bpf”, wyłączenie kompilatora BPF JIT i kilka innych “podatnych atrakcji”).

Można też użyć kontenerów typu lxc wykorzystujących “przestrzeń nazw użytkownika” (ale tu trzeba zostawić “clone newuser” dla nieuprawnionych użytkowników włączone – używanie kontenera, który korzysta z tego mechanizmu jest bezpieczniejsze od startowania takich kontenerów jako root).

Można też użyć dystrybucji z bardziej nastawionymi na bezpieczeństwo flagami gcc używanymi do kompilacji oprogramowania. Warte uwagi są też dystrybucje wprowadzające kompleksowy model zabezpieczeń typu Qubes-OS.

Inne techniki hardeningu też są dostępne, ale wyszedłby o tym artykuł (i nie byłby to tylko jeden artykuł, ale kilkanaście artykułów opisujących same podstawy, możliwości, sposób działania oraz wady i zalety danych rozwiązań) a nie komentarz.

Windows:
System z wgranymi wszystkimi łatkami bezpieczeństwa – standard. Dbanie o aktualność oprogramowania – bywa ciężej, ale się da. Wyłączenie nieużywanych “potencjalnie exploitowalnych” usług oraz funkcji systemu. Praca na koncie ze standardowymi uprawnieniami powinna być też oczywistością. UAC na najwyższym poziomie też może pomóc na wypadek prób zmiany ustawień systemowych przez złośliwe oprogramowanie.

“Na wszelki wypadek” pod Windowsami – klasyczne sandboxy jako podstawowa linia obrony odpadają – przepuszczają ataki złośliwymi czcionkami oraz błędami związanymi z renderowaniem interfejsu. Nie zabezpieczają też przed przechwytywaniem danych z interfejsu innych okien oraz na odwrót (zupełnie tak jak “klasyczne” X-y – nie zapewniają należytej izolacji bo nikt ich z tą myślą nie tworzył, a muszą tak działać by zachować “kompatybilność wsteczną”).

EMET (Enhanced Mitigation Experience Toolkit) jest niezłym narzędziem (oraz ciężkim do zastąpienia – niestety jego wsparcie kończy się w czerwcu 2018r). Część jego możliwości wprowadzono do Windowsa 10 oraz Windows Server 2016. Kilka innych trafiło jako mechanizmy w Windows defender dla Win10 i Win2016Server – im “bogatsza” wersja, tym więcej opcji. Szkoda tylko, że nawet “wypasiona wersja” Win10 Enterprise + włączone wszystkie wzięte z EMET-a funkcjonalności nie zapewniają tylu mechanizmów obrony co sam EMET (ale widać tendencję do portowania funkcjonalności EMET-a do samego systemu oraz próbę poradzenia sobie ze starymi wadami typu “it’s not a bug – it’s a feature”).

Z łatwo dostępnego softu – Malwarebytes Anti-Exploit też zapewnia ochronę przeciwko exploitom – wygląda przystępnie dla niedoświadczonego użytkownika. Szczegółów technicznych oraz porównania tutaj niestety nie mam.

Widać też lepsze podejście Microsoftu do implementacji auto-ochrony kluczowych mechanizmów ochronnych oraz bardziej wystawionych na ataki mechanizmów – opierają się one o uruchamianie takich komponentów w bardzo ograniczonym kontenerze wykorzystując HyperV (przykład takiego mechanizmu jest próba wprowadzenia opcjonalnego, “bezpieczniejszego trybu” przeglądarki Edge, który ma lepiej zabezpieczać przed atakami złośliwymi czcionkami).