{"id":29880,"date":"2019-10-31T21:32:27","date_gmt":"2019-10-31T18:32:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux\/"},"modified":"2019-10-31T21:32:27","modified_gmt":"2019-10-31T18:32:27","slug":"milliony-binarnikov-spustya-kak-ukreplyalsya-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux","title":{"rendered":"Miliony binarek p\u00f3\u017aniej. Jak wzmacnia\u0142 si\u0119 Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MilionyTL;DR<\/b>. W tym artykule badamy schematy zabezpiecze\u0144 (hardening schemes), kt\u00f3re dzia\u0142aj\u0105 \u201eprosto z pude\u0142ka\u201d w pi\u0119ciu popularnych dystrybucjach Linuksa. Dla ka\u017cdej z nich przyj\u0119li\u015bmy domy\u015bln\u0105 konfiguracj\u0119 j\u0105dra, zainstalowali\u015bmy wszystkie pakiety i przeanalizowali\u015bmy schematy ochrony w zagnie\u017cd\u017conych plikach binarnych. Rozwa\u017cane s\u0105 dystrybucje OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 i 7, oraz Ubuntu 14.04, 12.04 i 18.04 LTS. <\/p>\n

Wyniki potwierdzaj\u0105, \u017ce nawet podstawowe schematy, takie jak kanarki na stosie i kod niezale\u017cny od pozycji, nadal nie s\u0105 powszechnie stosowane. Sytuacja jest jeszcze gorsza w przypadku kompilator\u00f3w, je\u015bli chodzi o zabezpieczanie przed podatno\u015bciami, takimi jak ataki na stos (stack clash), kt\u00f3re znalaz\u0142y si\u0119 w centrum uwagi w styczniu po opublikowaniu informacji o podatno\u015bciach w systemd<\/a><\/noindex>. Ale nie wszystko jest beznadziejne. W znacznej cz\u0119\u015bci binari\u00f3w wdro\u017cono podstawowe metody ochrony, a ich liczba ro\u015bnie z wersji na wersj\u0119. <\/p>\n

Kontrola wykaza\u0142a, \u017ce najwi\u0119cej metod zabezpiecze\u0144 wdro\u017cono w Ubuntu 18.04 na poziomie systemu operacyjnego i aplikacji, nast\u0119pnie w Debianie 9. Z drugiej strony, podstawowe schematy ochrony zosta\u0142y r\u00f3wnie\u017c wdro\u017cone w OpenSUSE 12.4, CentOS 7 i RHEL 7, a zabezpieczanie przed atakami na stos stosowane jest szerzej w kontek\u015bcie bardziej zwartej podstawowej puli pakiet\u00f3w.
\n<\/a><\/noindex><\/p>\n

Wprowadzenie<\/h1>\n

\nTrudno jest zapewni\u0107 wysok\u0105 jako\u015b\u0107 oprogramowania. Pomimo ogromnej liczby zaawansowanych narz\u0119dzi do statycznej analizy kodu i dynamiki analizy w czasie wykonywania, oraz znacznego post\u0119pu w rozwoju kompilator\u00f3w i j\u0119zyk\u00f3w programowania, wsp\u00f3\u0142czesne oprogramowanie wci\u0105\u017c cierpi na podatno\u015bci, kt\u00f3re s\u0105 stale wykorzystywane przez przest\u0119pc\u00f3w. Sytuacja jest jeszcze gorsza w ekosystemach, kt\u00f3re obejmuj\u0105 przestarza\u0142y kod. W takich przypadkach nie tylko stykamy si\u0119 z nieustannym problemem poszukiwania potencjalnych b\u0142\u0119d\u00f3w do wykorzystania, ale jeste\u015bmy r\u00f3wnie\u017c ograniczeni przez sztywne ramy zgodno\u015bci wstecznej, kt\u00f3re cz\u0119sto wymagaj\u0105 zachowania ograniczonego, a jeszcze gorzej, podatnego lub wadliwego kodu.<\/p>\n

Tutaj w gr\u0119 wchodz\u0105 metody ochrony lub wzmocnienia oprogramowania (hardening). Niekt\u00f3rych typ\u00f3w b\u0142\u0119d\u00f3w nie jeste\u015bmy w stanie unikn\u0105\u0107, ale mo\u017cemy utrudni\u0107 \u017cycie przest\u0119pcy i cz\u0119\u015bciowo rozwi\u0105za\u0107 problem, zapobiegaj\u0105c lub uniemo\u017cliwiaj\u0105c eksploatacj\u0119<\/i> tych b\u0142\u0119d\u00f3w. Taka ochrona jest stosowana w nowoczesnych systemach operacyjnych, jednak metody znacznie r\u00f3\u017cni\u0105 si\u0119 pod wzgl\u0119dem z\u0142o\u017cono\u015bci, skuteczno\u015bci i wydajno\u015bci: od kanarek stosowych (stack canaries) i ASLR<\/a><\/noindex> do pe\u0142nych zabezpiecze\u0144 CFI<\/a><\/noindex> i ROP<\/a><\/noindex>. W tym artykule om\u00f3wimy, jakie metody ochrony s\u0105 stosowane w najpopularniejszych dystrybucjach Linuxa w konfiguracji domy\u015blnej oraz przyjrzymy si\u0119 w\u0142a\u015bciwo\u015bciom binari\u00f3w dystrybuowanych za po\u015brednictwem system\u00f3w zarz\u0105dzania pakietami ka\u017cdej dystrybucji.<\/p>\n

CVE i bezpiecze\u0144stwo<\/h3>\n

\nWszyscy widzieli\u015bmy artyku\u0142y o tytu\u0142ach takich jak \u201eNajbardziej podatne aplikacje roku\u201d lub \u201eNajbardziej podatne systemy operacyjne\u201d. Zwykle zawieraj\u0105 one statystyki og\u00f3lnej liczby zg\u0142osze\u0144 o podatno\u015bci typu CVE (Common Vulnerability and Exposures)<\/a><\/noindex>, uzyskanej z Krajowej bazy podatno\u015bci (NVD)<\/a><\/noindex> od NIST<\/a><\/noindex> i innych \u017ar\u00f3de\u0142. Nast\u0119pnie te aplikacje lub systemy operacyjne s\u0105 klasyfikowane wed\u0142ug liczby CVE. Niestety, chocia\u017c CVE s\u0105 bardzo pomocne w \u015bledzeniu problem\u00f3w i informowaniu dostawc\u00f3w oraz u\u017cytkownik\u00f3w, niewiele m\u00f3wi\u0105 o rzeczywistym bezpiecze\u0144stwie oprogramowania.<\/p>\n

Na przyk\u0142ad, przyjrzyjmy si\u0119 ca\u0142kowitej liczbie CVE w ci\u0105gu ostatnich czterech lat dla j\u0105dra Linux oraz pi\u0119ciu najpopularniejszych dystrybucji serwerowych, a mianowicie Ubuntu, Debian, Red Hat Enterprise Linux i OpenSUSE.<\/p>\n

\"Miliony
\nRys. 1<\/i><\/p>\n

Co m\u00f3wi nam ten wykres? Czy wi\u0119ksza liczba CVE oznacza, \u017ce jedna dystrybucja jest bardziej podatna ni\u017c inna? Odpowiedzi na to nie ma. Na przyk\u0142ad w tym artykule zobaczycie, \u017ce w Debianie zaimplementowano bardziej rygorystyczne mechanizmy zabezpiecze\u0144 w por\u00f3wnaniu do OpenSUSE czy Red Hat Linux, a mimo to Debian ma wi\u0119cej CVE. Jednak nie oznacza to koniecznie os\u0142abienia bezpiecze\u0144stwa: nawet obecno\u015b\u0107 CVE nie m\u00f3wi, czy podatno\u015b\u0107 jest wykorzystywalna<\/i>. Wyniki powagi daj\u0105 wyobra\u017cenie o tym, jak prawdopodobne<\/i> jest wykorzystanie podatno\u015bci, ale ostatecznie wykorzystywalno\u015b\u0107 w du\u017cej mierze zale\u017cy od zabezpiecze\u0144 obecnych w dotkni\u0119tych systemach oraz od zasob\u00f3w i mo\u017cliwo\u015bci przest\u0119pc\u00f3w. Co wi\u0119cej, brak zg\u0142osze\u0144 CVE niewiele m\u00f3wi o innych niezarejestrowanych lub nieznanych<\/i> W zakresie luk. R\u00f3\u017cnice w CVE mog\u0105 by\u0107 wynikiem nie tylko jako\u015bci oprogramowania, ale tak\u017ce innych czynnik\u00f3w, takich jak zasoby przeznaczone na testowanie czy wielko\u015b\u0107 bazy u\u017cytkownik\u00f3w. W naszym przyk\u0142adzie wi\u0119ksza liczba CVE w Debianie mo\u017ce po prostu wskazywa\u0107 na to, \u017ce Debian dostarcza wi\u0119cej pakiet\u00f3w oprogramowania. <\/p>\n

Oczywi\u015bcie system CVE daje przydatne informacje, kt\u00f3re pozwalaj\u0105 na tworzenie odpowiednich zabezpiecze\u0144. Im lepiej rozumiemy przyczyny awarii programu, tym \u0142atwiej okre\u015bli\u0107 mo\u017cliwe sposoby wykorzystania i opracowa\u0107 odpowiednie mechanizmy wykrywania i reagowania<\/i>. Na rys. 2 pokazane s\u0105 kategorie luk dla wszystkich dystrybucji w ci\u0105gu ostatnich czterech lat (ClickHouse-Ninja\/Proton<\/a><\/noindex>). Od razu wida\u0107, \u017ce wi\u0119kszo\u015b\u0107 CVE trafia do nast\u0119puj\u0105cych kategorii: atak typu denial of service (DoS), wykonanie kodu, przepe\u0142nienie, uszkodzenie pami\u0119ci, wyciek informacji i eskalacja przywilej\u00f3w. Chocia\u017c wiele CVE jest uj\u0119tych kilkakrotnie w r\u00f3\u017cnych kategoriach, w og\u00f3lnym uj\u0119ciu te same problemy utrzymuj\u0105 si\u0119 z roku na rok. W nast\u0119pnej cz\u0119\u015bci artyku\u0142u ocenimy wykorzystanie r\u00f3\u017cnych schemat\u00f3w ochrony w celu zapobie\u017cenia eksploatacji wskazanych luk.<\/p>\n

\"Miliony
\nRys. 2<\/i><\/p>\n

Zadania<\/h3>\n

\nW tym artykule zamierzamy odpowiedzie\u0107 na nast\u0119puj\u0105ce pytania:<\/p>\n