Firma Checkpoint Mechanizm ochronny Safe-Linking, który utrudnia tworzenie exploitów manipulujących definicją lub modyfikacją wskaźników do buforów przydzielanych podczas wykonywania wywołania malloc. Safe-Linking nie blokuje całkowicie możliwości wykorzystania luk, ale przy minimalnym nakładzie znacznie komplikuje tworzenie niektórych kategorii exploitów, ponieważ oprócz przepełnienia bufora możliwego do wykorzystania konieczne jest znalezienie innej luki, która powoduje wyciek informacji o umieszczenie sterty w pamięci.
Poprawki implementujące Safe-Linking zostały przygotowane dla Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) i Google TCmalloc, a także proponowane są w celu modernizacji ochrony w Chromium (w
Od 2012 roku Chromium ma już wbudowaną technikę ochrony MaskPtr mającą na celu rozwiązanie tego samego problemu, ale rozwiązanie firmy Checkpoint wykazuje wyższą wydajność).
Sugerowane poprawki zostały już zatwierdzone do dostarczenia w wydaniu sierpniowym i Safe-Linking będą domyślnie włączone. uClibc-NG obsługuje bezpieczne łączenie zawarte w wersji 1.0.33 i jest domyślnie włączone. Zmiany w gperftools (stary tcmalloc) , ale będzie oferowana jako opcja w przyszłej wersji.
Deweloperzy (nowy tcmalloc) odmówił przyjęcia , powołując się na poważne pogorszenie wydajności i potrzebę dodawania szeroko zakrojonych testów w celu regularnego sprawdzania, czy wszystko działa zgodnie z oczekiwaniami. Testy przeprowadzone przez inżynierów Checkpoint wykazały, że metoda Safe-Linking nie prowadzi do dodatkowego zużycia pamięci, a wydajność podczas wykonywania operacji na stercie spada średnio zaledwie o 0.02%, a w najgorszym przypadku o 1.5% (dla porównania koszty ogólne w metodzie stosowanej w Chromium szacuje się na „mniej niż 2%”). Włączenie
Funkcja Safe-Linking powoduje wykonanie 2-3 dodatkowych instrukcji asemblera przy każdym wywołaniu free() i 3-4 instrukcje przy każdym wywołaniu malloc(). Uruchamianie etapów inicjalizacji i generowania wartości losowych nie jest wymagane.
Safe-Linking można wykorzystać nie tylko do poprawy bezpieczeństwa różnych implementacji sterty, ale także do dodania kontroli integralności do dowolnych struktur danych, które korzystają z pojedynczo połączonych list wskaźników umieszczonych obok samych buforów. Metoda jest bardzo prosta w implementacji i wymaga jedynie dodania jednego makra i zastosowania go do wskaźników do kolejnego bloku w kodzie (np. dla Glibc tylko kilka linijek kodu). Metoda sprowadza się do następujących zmian:
+#definiuj PROTECT_PTR(pos, ptr) \
+ ((__typeof (ptr)) ((((rozmiar_t) poz) >> 12) ^ ((rozmiar_t) ptr)))
+#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)
- następnyp = p->fd;
+ następnyp = REVEAL_PTR (p->fd);
...
Istotą tej metody jest wykorzystanie losowych danych z mechanizmu randomizacji adresów ASLR (mmap_base) do ochrony list pojedynczo połączonych, takich jak Fast-Bins i TCache. Zanim wartość zostanie zastosowana do wskaźnika następnego elementu na liście, przeprowadza konwersję maski i sprawdza wyrównanie strony. Wskaźnik zostaje zastąpiony wynikiem operacji „(L >> PAGE_SHIFT) XOR (P)”, gdzie P jest wartością wskaźnika, a L jest komórką pamięci, w której przechowywany jest wskaźnik.
Kiedy jest używany w systemie (Randomizacja układu przestrzeni adresowej) część L bitów z adresem bazowym sterty zawiera losowe wartości, które służą jako klucz do zakodowania P (wyodrębnione przez operację przesunięcia 12-bitowego dla stron 4096-bajtowych). Ta manipulacja zmniejsza ryzyko przejęcia wskaźnika w exploitze, ponieważ wskaźnik nie jest przechowywany w swojej oryginalnej formie, a jego zastąpienie wymaga wiedzy na temat alokacji sterty. Dodatkowo patch code zawiera również dodatkową kontrolę wyrównania bloków, która nie pozwala atakującemu na zastąpienie wskaźnika niewyrównaną wartością i wymaga znajomości liczby wyrównanych bitów, co w systemach 64-bitowych dodatkowo umożliwia blokowanie 15 z 16 prób ataku, które nie uwzględniają ustawienia.
Metoda ta jest skuteczna w ochronie przed atakami wykorzystującymi częściowe przepisanie wskaźnika (zmiana małych bajtów), całkowite przepisanie wskaźnika (przekierowanie do kodu atakującego) i zmianę pozycji listy pod niewyrównanym adresem. Jako przykład pokazano, że użycie Safe-Linking w malloc umożliwiłoby ostatnio zablokowanie wykorzystania przez tych samych badaczy podatności w inteligentnym oświetleniu Philips Hue Bridge, spowodowanym przepełnieniem bufora i umożliwiającym przejęcie kontroli nad urządzeniem.
Źródło: opennet.ru