TL;DR. W tym artykule badamy schematy zabezpieczeń (hardening schemes), które działają „prosto z pudełka” w pięciu popularnych dystrybucjach Linuksa. Dla każdej z nich przyjęliśmy domyślną konfigurację jądra, zainstalowaliśmy wszystkie pakiety i przeanalizowaliśmy schematy ochrony w zagnieżdżonych plikach binarnych. Rozważane są dystrybucje OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 i 7, oraz Ubuntu 14.04, 12.04 i 18.04 LTS.
Wyniki potwierdzają, że nawet podstawowe schematy, takie jak kanarki na stosie i kod niezależny od pozycji, nadal nie są powszechnie stosowane. Sytuacja jest jeszcze gorsza w przypadku kompilatorów, jeśli chodzi o zabezpieczanie przed podatnościami, takimi jak ataki na stos (stack clash), które znalazły się w centrum uwagi w styczniu po opublikowaniu . Ale nie wszystko jest beznadziejne. W znacznej części binariów wdrożono podstawowe metody ochrony, a ich liczba rośnie z wersji na wersję.
Kontrola wykazała, że najwięcej metod zabezpieczeń wdrożono w Ubuntu 18.04 na poziomie systemu operacyjnego i aplikacji, następnie w Debianie 9. Z drugiej strony, podstawowe schematy ochrony zostały również wdrożone w OpenSUSE 12.4, CentOS 7 i RHEL 7, a zabezpieczanie przed atakami na stos stosowane jest szerzej w kontekście bardziej zwartej podstawowej puli pakietów.
Wprowadzenie
Trudno jest zapewnić wysoką jakość oprogramowania. Pomimo ogromnej liczby zaawansowanych narzędzi do statycznej analizy kodu i dynamiki analizy w czasie wykonywania, oraz znacznego postępu w rozwoju kompilatorów i języków programowania, współczesne oprogramowanie wciąż cierpi na podatności, które są stale wykorzystywane przez przestępców. Sytuacja jest jeszcze gorsza w ekosystemach, które obejmują przestarzały kod. W takich przypadkach nie tylko stykamy się z nieustannym problemem poszukiwania potencjalnych błędów do wykorzystania, ale jesteśmy również ograniczeni przez sztywne ramy zgodności wstecznej, które często wymagają zachowania ograniczonego, a jeszcze gorzej, podatnego lub wadliwego kodu.
Tutaj w grę wchodzą metody ochrony lub wzmocnienia oprogramowania (hardening). Niektórych typów błędów nie jesteśmy w stanie uniknąć, ale możemy utrudnić życie przestępcy i częściowo rozwiązać problem, zapobiegając lub uniemożliwiając eksploatację tych błędów. Taka ochrona jest stosowana w nowoczesnych systemach operacyjnych, jednak metody znacznie różnią się pod względem złożoności, skuteczności i wydajności: od kanarek stosowych (stack canaries) i do pełnych zabezpieczeń i . W tym artykule omówimy, jakie metody ochrony są stosowane w najpopularniejszych dystrybucjach Linuxa w konfiguracji domyślnej oraz przyjrzymy się właściwościom binariów dystrybuowanych za pośrednictwem systemów zarządzania pakietami każdej dystrybucji.
CVE i bezpieczeństwo
Wszyscy widzieliśmy artykuły o tytułach takich jak „Najbardziej podatne aplikacje roku” lub „Najbardziej podatne systemy operacyjne”. Zwykle zawierają one statystyki ogólnej liczby zgłoszeń o podatności typu , uzyskanej z od i innych źródeł. Następnie te aplikacje lub systemy operacyjne są klasyfikowane według liczby CVE. Niestety, chociaż CVE są bardzo pomocne w śledzeniu problemów i informowaniu dostawców oraz użytkowników, niewiele mówią o rzeczywistym bezpieczeństwie oprogramowania.
Na przykład, przyjrzyjmy się całkowitej liczbie CVE w ciągu ostatnich czterech lat dla jądra Linux oraz pięciu najpopularniejszych dystrybucji serwerowych, a mianowicie Ubuntu, Debian, Red Hat Enterprise Linux i OpenSUSE.
Rys. 1
Co mówi nam ten wykres? Czy większa liczba CVE oznacza, że jedna dystrybucja jest bardziej podatna niż inna? Odpowiedzi na to nie ma. Na przykład w tym artykule zobaczycie, że w Debianie zaimplementowano bardziej rygorystyczne mechanizmy zabezpieczeń w porównaniu do OpenSUSE czy Red Hat Linux, a mimo to Debian ma więcej CVE. Jednak nie oznacza to koniecznie osłabienia bezpieczeństwa: nawet obecność CVE nie mówi, czy podatność jest wykorzystywalna. Wyniki powagi dają wyobrażenie o tym, jak prawdopodobne jest wykorzystanie podatności, ale ostatecznie wykorzystywalność w dużej mierze zależy od zabezpieczeń obecnych w dotkniętych systemach oraz od zasobów i możliwości przestępców. Co więcej, brak zgłoszeń CVE niewiele mówi o innych niezarejestrowanych lub nieznanych W zakresie luk. Różnice w CVE mogą być wynikiem nie tylko jakości oprogramowania, ale także innych czynników, takich jak zasoby przeznaczone na testowanie czy wielkość bazy użytkowników. W naszym przykładzie większa liczba CVE w Debianie może po prostu wskazywać na to, że Debian dostarcza więcej pakietów oprogramowania.
Oczywiście system CVE daje przydatne informacje, które pozwalają na tworzenie odpowiednich zabezpieczeń. Im lepiej rozumiemy przyczyny awarii programu, tym łatwiej określić możliwe sposoby wykorzystania i opracować odpowiednie mechanizmy wykrywania i reagowania. Na rys. 2 pokazane są kategorie luk dla wszystkich dystrybucji w ciągu ostatnich czterech lat (). Od razu widać, że większość CVE trafia do następujących kategorii: atak typu denial of service (DoS), wykonanie kodu, przepełnienie, uszkodzenie pamięci, wyciek informacji i eskalacja przywilejów. Chociaż wiele CVE jest ujętych kilkakrotnie w różnych kategoriach, w ogólnym ujęciu te same problemy utrzymują się z roku na rok. W następnej części artykułu ocenimy wykorzystanie różnych schematów ochrony w celu zapobieżenia eksploatacji wskazanych luk.
Rys. 2
Zadania
W tym artykule zamierzamy odpowiedzieć na następujące pytania:
- Jakie jest bezpieczeństwo różnych dystrybucji Linuxa? Jakie mechanizmy ochrony istnieją w jądrze i aplikacjach przestrzeni użytkownika?
- Jak w czasie zmieniało się przyjęcie mechanizmów ochrony dla różnych dystrybucji?
- Jakie są średnie zależności pakietów i bibliotek dla każdej dystrybucji?
- Jakie zabezpieczenia wprowadzono dla każdego binarnego pliku?
Wybór dystrybucji
Okazuje się, że trudno znaleźć dokładną statystykę dotyczącą instalacji dystrybucji, ponieważ w większości przypadków liczba pobrań nie wskazuje na liczbę rzeczywistych instalacji. Niemniej jednak, systemy Unix stanowią większość serwerów (na serwerach WWW 69,2%, według W3techs i innych źródeł), a ich udział stale rośnie. W związku z tym w naszym badaniu skoncentrowaliśmy się na dystrybucjach dostępnych z pudełka na platformie . W szczególności wybraliśmy następujące systemy operacyjne:
Dystrybucja/wersja
Jądro
Build
OpenSUSE 12.4
4.12.14-95.3-default
#1 SMP Wed Dec 5 06:00:48 UTC 2018 (63a8d29)
Debian 9 (stretch)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)
CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP Tue Jan 15 17:07:28 UTC 2019
CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP Fri Feb 1 14:54:57 UTC 2019
Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP Wed Nov 21 15:08:21 EST 2018
Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Thu Nov 15 17:36:42 UTC 2018
Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-generic
#166~14.04.1-Ubuntu SMP Sat Nov 17 01:52:43 UTC 20…
Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP Fri Dec 7 09:59:47 UTC 2018
Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27-Ubuntu SMP Thu Dec 6 18:27:01 UTC 2018
Tabela 1
Analiza
Przeanalizujemy domyślną konfigurację jądra oraz właściwości pakietów dostępnych przez menedżera pakietów w każdym dystrybucji z pudełka. W ten sposób bierzemy pod uwagę tylko pakiety z domyślnych lustrzanych odbić każdej dystrybucji, ignorując pakiety z niestabilnych repozytoriów (np. lustra 'testing' w Debianie) oraz pakiety zewnętrzne (np. pakiety Nvidia z domyślnych lustrzanek). Ponadto nie uwzględniamy niestandardowych kompilacji jądra ani konfiguracji z podwyższonym poziomem zabezpieczeń.
Analiza konfiguracji jądra
Zastosowaliśmy skrypt analizy oparty na . Rozważamy domyślne parametry zabezpieczeń w wymienionych dystrybucjach i porównujemy je z listą od (KSPP). Dla każdego parametru konfiguracji tabela 2 opisuje pożądaną konfigurację: zaznaczenie dotyczy dystrybucji, które spełniają zalecenia KSSP (wyjaśnienie terminów przedstawione jest ; w przyszłych artykułach opiszemy, jak powstały wiele z tych metod zabezpieczeń i jak zhakować system w ich braku).
Ogólnie rzecz biorąc, nowsze jądra mają bardziej rygorystyczne ustawienia z pudełka. Na przykład w CentOS 6.10 i RHEL 6.10 na jądrze 2.6.32 brakuje większości krytycznych funkcji wprowadzanych w nowszych jądrach, takich jak , rygorystyczne uprawnienia RWX, randomizacja adresów czy ochrona copy2usr. Należy zauważyć, że wiele opcji konfiguracyjnych z tabeli jest niedostępnych w starszych wersjach jądra i nie ma zastosowania w rzeczywistości - w tabeli mimo to zaznaczone jest to jako brak odpowiednich zabezpieczeń. Podobnie, jeśli dany parametr konfiguracyjny jest niedostępny w danej wersji, a dla bezpieczeństwa ten parametr należy wyłączyć, to uznaje się to za rozsądne ustawienie.
Kolejny aspekt interpretacji wyników: niektóre konfiguracje jądra, które zwiększają powierzchnię ataku, mogą jednocześnie być używane dla zapewnienia bezpieczeństwa. Przykłady to uprobes i kprobes, moduły jądra oraz BPF/eBPF. Nasza rekomendacja to wykorzystanie powyższych mechanizmów w celu zapewnienia rzeczywej ochrony, ponieważ ich użycie nie jest proste, a ich eksploatacja zakłada, że złośliwi podmioty już osiedliły się w systemie. Jeśli jednak te opcje są włączone, administrator systemu powinien aktywnie monitorować nadużycia.
Analizując dalej zapisy z tabeli 2, widzimy, że nowoczesne jądra oferują kilka opcji ochrony przed eksploatacją takich luk, jak wycieki informacji oraz nadpisanie stosu/sterty. Jednak zauważamy, że nawet najnowsze popularne dystrybucje jeszcze nie wdrożyły bardziej zaawansowanej ochrony (na przykład z łatkami ), ani nowoczesnej ochrony przed atakami ponownego użycia kodu (na przykład, ). Co gorsza, nawet te bardziej zaawansowane środki ochrony nie chronią przed pełnym zakresem ataków. Dlatego niezwykle ważne jest, aby administratorzy systemu uzupełniali rozsądne konfiguracje rozwiązaniami, które oferują wykrywanie i zapobieganie eksploatom w czasie rzeczywistym.
Analiza aplikacji
Nic dziwnego, że różne dystrybucje mają różne specyfikacje pakietów, opcje kompilacji, zależności bibliotek itp. Różnice istnieją nawet dla dystrybucji i pakietów z niewielką ilością zależności (na przykład coreutils w Ubuntu lub Debianie). Aby ocenić różnice, pobraliśmy wszystkie dostępne pakiety, wyodrębniliśmy ich zawartość i przeanalizowaliśmy pliki binarne oraz zależności. Dla każdego pakietu śledziliśmy inne pakiety, od których zależy, a dla każdego binarnego śledziliśmy jego zależności. W tej części krótko podsumujemy wnioski.
Dystrybucje
Łącznie załadowaliśmy 361 556 pakietów dla wszystkich dystrybucji, pobierając tylko pakiety z domyślnych luster. Zignorowaliśmy pakiety bez plików wykonywalnych ELF, takie jak kody źródłowe, czcionki itd. Po filtracji pozostało 129 569 pakietów, zawierających łącznie 584 457 plików binarnych. Rozkład pakietów i plików według dystrybucji przedstawiono na rys. 3.
Rys. 3
Można zauważyć, że im nowsza dystrybucja, tym więcej zawiera pakietów i plików binarnych, co jest logiczne. Pakiety Ubuntu i Debian zawierają znacznie więcej plików binarnych (zarówno wykonywalnych, jak i dynamicznych modułów i bibliotek) niż CentOS, SUSE i RHEL, co potencjalnie wpływa na powierzchnię ataku Ubuntu i Debiana (warto zauważyć, że liczby odzwierciedlają wszystkie binarki wszystkich wersji pakietu, co oznacza, że niektóre pliki są analizowane wielokrotnie). Jest to szczególnie ważne, biorąc pod uwagę zależności między pakietami. W ten sposób, luka w binarze jednego pakietu może wpłynąć na wiele części ekosystemu, jak podatna biblioteka może wpłynąć na wszystkie pliki binarne, które ją importują. Jako punkt odniesienia przyjrzyjmy się rozkładowi liczby zależności w pakietach w różnych systemach operacyjnych:
Rys. 4
W prawie wszystkich dystrybucjach 60% pakietów ma co najmniej 10 zależności. Ponadto, niektóre pakiety mają znacznie większą liczbę zależności (ponad 100). To samo dotyczy odwrotnych zależności pakietów: jak można się spodziewać, kilka pakietów jest używanych przez wiele innych pakietów w dystrybucji, dlatego luki w tych nielicznych wybranych mają wysokie ryzyko. Jako przykład w poniższej tabeli wymieniono 20 pakietów z największą liczbą odwrotnych zależności w SLES, CentOS 7, Debian 9 i Ubuntu 18.04 (w każdej komórce podano oznaczenie pakietu oraz liczbę odwrotnych zależności).
Tabela 3
Ciekawostka. Chociaż wszystkie analizowane systemy operacyjne są zbudowane dla architektury x86_64, a u większości pakietów architektura określona jest jako x86_64 i x86, pakiety często zawierają pliki binarne dla innych architektur, jak pokazano na rys. 5.
Rys. 5
W następnej sekcji zagłębimy się w charakterystyki analizowanych binarek.
Statystyka ochrony plików binarnych
Jako absolutne minimum należy zapoznać się z podstawowym zestawem opcji zabezpieczeń dla dostępnych plików binarnych. Kilka dystrybucji Linuxa dostarczane jest ze skryptami, które wykonują takie kontrole. Na przykład w Debianie/Ubuntu znajduje się taki skrypt. Oto przykład jego działania:
$ hardening-check $(which docker)
/usr/bin/docker:
Wykonywalny niezależny od pozycji: tak
Stos chroniony: tak
Funkcje Fortify Source: nie, znaleziono tylko funkcje niezabezpieczone!
Przenoszenia tylko do odczytu: tak
Natychmiastowe wiązanie: takSkrypt sprawdza pięć :
- Wykonywalny niezależny od pozycji (PIE): wskazuje, czy można przenieść w pamięci sekcję tekstową programu, aby osiągnąć losowość, jeśli w jądrze jest włączony ASLR.
- Chroniony stos: czy włączono kanarki stosu w celu ochrony przed atakami na kolizję stosu.
- Fortify Source: czy niebezpieczne funkcje (np. strcpy) są zastępowane ich bezpiecznymi odpowiednikami, a wywołania kontrolowane w czasie wykonywania – ich niekontrolowanymi odpowiednikami (np. memcpy zamiast __memcpy_chk).
- Przeniesienia tylko do odczytu (RELRO): czy wpisy tabeli przeniesień są oznaczone jako «tylko do odczytu», jeśli zostały zastosowane przed rozpoczęciem wykonywania.
- Natychmiastowe wiązanie: czy linker czasu wykonania załatwia wszystkie przeniesienia przed rozpoczęciem wykonywania programu (to jest równoznaczne z pełnym RELRO).
Czy powyższe mechanizmy są wystarczające? Niestety, nie. Są znane sposoby omijania wszystkich wymienionych zabezpieczeń, ale im bardziej rygorystyczna ochrona, tym wyższy próg dla atakującego. Na przykład, są trudniejsze do zastosowania, jeśli działa PIE i natychmiastowe wiązanie. Podobnie pełny ASLR wymaga dodatkowej pracy w celu stworzenia działającego exploit. Jednak wyrafinowani przestępcy są już gotowi na takie zabezpieczenia: ich brak zasadniczo przyspieszy włamanie. Dlatego niezwykle ważne jest, aby te środki były traktowane jako niezbędne minimum.
Chcieliśmy zbadać, jak wiele plików binarnych w badanych dystrybucjach jest zabezpieczonych tymi, a także trzema innymi metodami:
- Bit niewykonywalny () zapobiega wykonywaniu w każdym obszarze, który nie powinien być wykonywalny, na przykład w stosie pamięci itp.
- oznacza ścieżkę wykonywania, używaną przez dynamicznego ładowacza do wyszukiwania odpowiednich bibliotek. Pierwszy jest obowiązkowy dla każdego nowoczesnego systemu: jego brak pozwala napastnikom na dowolne zapisywanie ładunku w pamięci i wykonywanie go tak, jak jest. Po drugie, niewłaściwe konfiguracje ścieżek wykonywania sprzyjają wprowadzaniu niepewnego kodu, co może prowadzić do szeregu problemów (na przykład, , a także ).
- Ochrona przed kolizją stosów zapewnia ochronę przed atakami, które powodują, że stos nakłada się na inne obszary pamięci (na przykład, na stertę). Biorąc pod uwagę niedawne exploity wykorzystujące , uznaliśmy za stosowne włączyć ten mechanizm do naszego zestawu danych.
Tak więc, bez dalszych ceremonii, przejdźmy do liczb. Tabele 4 i 5 zawierają skrót analizy plików wykonywalnych i bibliotek różnych dystrybucji, odpowiednio.
- Jak można zauważyć, ochrona NX jest wdrażana wszędzie, z nielicznymi wyjątkami. W szczególności należy zauważyć nieco niższe jej wykorzystanie w dystrybucjach Ubuntu i Debian w porównaniu do CentOS, RHEL i OpenSUSE.
- Wielu dystrybucji brak jest canary stacks, szczególnie w tych z przestarzałymi jądrami. Znaczący postęp odnotowano w ostatnich dystrybucjach CentOS, RHEL, Debian i Ubuntu.
- Z wyjątkiem Debiana i Ubuntu 18.04, w większości dystrybucji słabo obsługiwane jest PIE.
- Ochrona przed kolizjami stosów jest słabo wdrażana w OpenSUSE, CentOS 7 i RHEL 7 oraz praktycznie nie występuje w innych.
- Wszystkie dystrybucje z nowoczesnymi jądrami mają pewne wsparcie dla RELRO, przy czym liderem jest Ubuntu 18.04, a na drugim miejscu jest Debian.
Jak już wspomniano, metryki w tej tabeli są średnie dla wszystkich wersji pliku binarnego. Jeśli spojrzymy tylko na najnowsze wersje plików, to liczby będą inne (na przykład, zob. ). Co więcej, większość dystrybucji podczas liczenia statystyk zazwyczaj sprawdza ochronę tylko kilku funkcji w kodzie binarnym, a w naszej analizie podany jest rzeczywisty procent wzmocnionych funkcji. Dlatego jeśli w binarce chronione jest 5 z 50 funkcji, przyznamy mu ocenę 0,1, co odpowiada 10% wzmocnionych funkcji.
Tabela 4. Cecha ochrony dla plików wykonywalnych przedstawionych na rys. 3 (wdrożenie odpowiednich funkcji w procentach od całkowitej liczby plików wykonywalnych)
Tabela 5. Cechy zabezpieczeń dla bibliotek pokazanych na rys. 3 (realizacja odpowiednich funkcji w procentach od ogólnej liczby bibliotek)
Czy jest postęp? Zdecydowanie tak: widać to w statystykach dotyczących poszczególnych dystrybucji (na przykład, ), a także w przedstawionych wyżej tabelach. Jako przykład na rys. 6 pokazano wdrażanie mechanizmów zabezpieczeń w trzech kolejnych dystrybucjach Ubuntu LTS 5 (pominęliśmy statystyki zabezpieczeń przed kolizją stosu). Zauważamy, że z wersji na wersję coraz więcej plików obsługuje kanarki stosu, a także sukcesywnie coraz więcej plików binarnych dostarczanych jest z pełną ochroną RELRO.
Rys. 6
Niestety, szereg plików wykonywalnych w różnych dystrybucjach nadal nie posiada żadnej z wymienionych powyżej ochron. Na przykład, patrząc na Ubuntu 18.04, można zauważyć binarkę ngetty (zamiennik getty), a także powłoki mksh i lksh, interpreter picolisp, pakiety nvidia-cuda-toolkit (popularny pakiet dla aplikacji z akceleracją GPU, takich jak ramy uczenia maszynowego) oraz klibc-utils. Podobnie, binarka mandos-client (narzędzie administracyjne, które automatycznie restartuje maszyny z zaszyfrowanymi systemami plików), a także rsh-redone-client (ponowna implementacja rsh i rlogin) są dostarczane bez ochrony NX, mimo że mają uprawnienia SUID :(. Ponadto w kilku binarkach SUID nie ma podstawowej ochrony, takiej jak kanarki stosu (na przykład, plik binarny Xorg.wrap z pakietu Xorg).
Podsumowanie i uwagi końcowe
W tym artykule przedstawiliśmy kilka właściwości bezpieczeństwa nowoczesnych dystrybucji Linuxa. Analiza wykazała, że w najnowszej wersji Ubuntu LTS (18.04) osiągnięto na ogół najsilniejsze zabezpieczenia na poziomie systemu operacyjnego i aplikacji wśród dystrybucji z relatywnie nowymi jądrami, takimi jak Ubuntu 14.04, 12.04 i Debian 9. Jednak omawiane dystrybucje CentOS, RHEL i OpenSUSE w naszym zbiorze danych domyślnie dostarczają bardziej rozbudowany zestaw pakietów, a w najnowszych wersjach (CentOS i RHEL) mają wyższy wskaźnik realizacji ochrony przed przepełnieniem stosu w porównaniu do rywali opartych na Debianie (Debian i Ubuntu). Porównując wersje CentOS i RedHat, zauważamy znaczne poprawy w wdrażaniu kanarek stosowych i RELRO z wersji 6 do 7, ale przeciętnie w CentOS jest wdrożonych więcej funkcji niż w RHEL. Ogólnie rzecz biorąc, wszystkie dystrybucje powinny zwrócić szczególną uwagę na ochronę PIE, która, poza Debianem 9 i Ubuntu 18.04, występuje w mniej niż 10% plików binarnych z naszego zbioru danych.
Na koniec warto zauważyć: chociaż badanie przeprowadziliśmy ręcznie, istnieje wiele narzędzi bezpieczeństwa (np. , , ), które wykonują analizę i pomagają unikać niebezpiecznych konfiguracji. Niestety, nawet silne zabezpieczenia w rozsądnych konfiguracjach nie gwarantują braku exploitów. Dlatego jesteśmy głęboko przekonani, że kluczowe jest zapewnienie , koncentrując się na wzorcach eksploatacji i zapobiegając im.
Źródło: habr.com
