Sprawdź punkt (globalny dostawca rozwiązań z zakresu bezpieczeństwa IT) wydał kilka dni temu wstęp mechanizmu bezpieczeństwa "Bezpieczne łączenie", oferuje nasz konfigurator utrudnia tworzenie exploitów które manipulują definicją lub zmianą wskaźników do przydzielonych buforów podczas wykonywania wywołania malloc.
Nowy mechanizm „Safe Linking” nie blokuje całkowicie możliwości wykorzystania luk w zabezpieczeniach, ale przy minimalnych kosztach komplikuje tworzenie pewnych kategorii exploitówJako że oprócz wykorzystanego przepełnienia bufora konieczne jest znalezienie kolejnej luki powodującej informację o położeniu stosu w pamięci.
Przygotowano łaty implementacyjne Safe-Linking dla Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) i Google TCMalloc, a także propozycję unowocześnienia ochrony w Chromium (od 2012 roku Chromium jest już zintegrowane z rozwiązaniami dla ten sam problem) Technika ochrony MaskPtr, ale rozwiązanie Checkpointa wykazuje lepszą wydajność).
Proponowane poprawki zostały już zatwierdzone do dostarczenia w sierpniowym wydaniu Glibc 3.32, a Bezpieczne łączenie będzie domyślnie włączone. W uClibc-NG obsługa bezpiecznego łącza została uwzględniona w wersji 1.0.33 i jest domyślnie włączona. W gperftools (stary tcmalloc) zmiany są akceptowane, ale będą oferowane jako opcja w przyszłej wersji.
Twórcy TCMalloc odmówili zaakceptowania zmiany, cz dużym sukcesem wydajnościowym i koniecznością dodawania zaawansowanych testów, aby regularnie weryfikować, czy wszystko działa poprawnie.
Testy przeprowadzone przez Inżynierowie punktu kontrolnego wykazali, że metoda Safe-Linking nie prowadzi do dodatkowego zużycia pamięci a wydajność podczas wykonywania operacji na stertach spada średnio tylko o 0.02%, aw najgorszym przypadku o 1.5%
Włączenie bezpiecznego łączenia prowadzi do wykonania 2-3 dodatkowych instrukcji asemblera przy każdym wywołaniu free () i 3-4 instrukcji podczas wywoływania malloc (). Początek inicjalizacji i generowanie wartości losowych nie są wymagane.
Safe-Linking można wykorzystać nie tylko do zwiększenia bezpieczeństwa różnych implementacji sterty, sino również w celu dodania kontroli integralności do dowolnej struktury danych który używa listy indywidualnie połączonych wskaźników znajdujących się obok buforów.
Metoda jest bardzo prosty w implementacji i wymaga jedynie dodania makra i zastosuj go do wskaźników do następnego bloku kodu (na przykład dla Glibc tylko kilka linii jest zmienianych w kodzie).
Istotą tej metody jest zastosowanie losowych danych z mechanizmu randomizacji adresów ASLR (mmap_base) w celu ochrony indywidualnie połączonych list, takich jak Fast-Bins i TCache. Przed zastosowaniem wartości wskaźnika do następnego elementu na liście, konwersja maski i sprawdzenie wyrównania są wykonywane wzdłuż krawędzi strony pamięci. Wskaźnik jest zastępowany wynikiem operacji „(L >> PAGE_SHIFT) XOR (P)”, gdzie P jest wartością wskaźnika, a L jest lokalizacją w pamięci, w której ten wskaźnik jest przechowywany.
W przypadku użycia w systemie ASLR (Address Space Layout Randomization), niektóre z bitów L z adresem bazowym sterty zawierają losowe wartości, które są używane jako klucz do kodowania P (są wyodrębniane przez przesunięcie operacji 12 bitów dla stron o rozmiarze 4096 bajtów).
Taka manipulacja zmniejsza ryzyko przechwycenia wskaźnika w exploicie, Ponieważ wskaźnik nie jest przechowywany w swojej pierwotnej postaci i aby go zastąpić, musisz znać informacje o lokalizacji sterty.
Metoda skutecznie chroni przed atakami wykorzystującymi częściową redefinicję wskaźnika (małe przesunięcie bajtów), całkowite przepisanie wskaźników (przekierowanie do kodu atakującego) i zmień pozycję listy w kierunku nie wyrównanym.
Jako przykład pokazano, że użycie Safe-Linking w malloc zablokowałoby wykorzystanie luki CVE-2020-6007 odkrytej niedawno przez tych samych badaczy w inteligentnym podświetleniu Philips Hue Bridge spowodowanym przepełnieniem bufora i umożliwiającej sterowanie urządzenie.
źródło: https://research.checkpoint.com