TL;DR. V tomto článku preskúmame ochranné schémy (hardening schemes), ktoré fungujú priamo v piatich populárnych distribúciách Linuxu. Pre každú sme vzali predvolenú konfiguráciu jadra, nainštalovali všetky balíky a analyzovali schémy ochrany vo vnorených binárnych súboroch. Zohľadňujeme distribúcie OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 a 7, ako aj Ubuntu 14.04, 12.04 a 18.04 LTS.

Výsledky potvrdzujú, že aj základné schémy, ako sú zásobníkové kanáriky a kód nezávislý od pozície, ešte nie sú vo všetkých používané. Situácia je ešte horšia pri kompilátoroch, pokiaľ ide o ochranu pred zraniteľnosťami, ako sú kolízie zásobníka (stack clash), ktoré sa dostali do centra pozornosti v januári po zverejnení informácií o zraniteľnostiach v systemd. Ale nie je všetko beznádejne. Vo významnej časti binárnych súborov sú implementované základné metódy ochrany a ich počet rastie z verzie na verziu.

Kontrola ukázala, že najväčší počet metód ochrany je implementovaný v Ubuntu 18.04 na úrovni OS a aplikácií, nasleduje Debian 9. Na druhej strane, v OpenSUSE 12.4, CentOS 7 a RHEL 7 sú tiež implementované základné schémy ochrany, pričom ochrana pred kolíziou zásobníka je aplikovaná ešte širšie pri oveľa hustejšom súbore balíkov podľa predvoleného nastavenia.

Úvod

Zabezpečiť vysokú kvalitu softvéru je ťažké. Napriek obrovskému množstvu pokročilých nástrojov na statickú analýzu kódu a dynamickú analýzu počas behu, ako aj významnému pokroku v vývoji kompilátorov a programovacích jazykov, moderný softvér stále trpí zraniteľnosťami, ktoré nepretržite zneužívajú útočníci. Situácia je ešte horšia v ekosystémoch, ktoré zahŕňajú zastaraný kód. V takýchto prípadoch sa nielenže stretávame s večným problémom vyhľadávania možných zneužívaných chýb, ale sme aj obmedzení prísnymi rámcami spätnej kompatibility, ktoré často vyžadujú zachovať obmedzený, ešte horšie zraniteľný alebo chybový kód.

Tu prichádzajú do hry metódy ochrany alebo zosilnenia softvéru (hardening). Niektoré typy chýb nemôžeme zabrániť, ale môžeme skomplikovať život útočníka a čiastočne vyriešiť problém, zabránením alebo prekážaním. využití týchto chýb. Takáto ochrana sa používa vo všetkých moderných operačných systémoch, avšak metódy sa výrazne líšia zložitosti, efektívnosti a výkonu: od zásobníkových kanárikov (stack canaries) a ASLR až po plnohodnotné ochrany CFI a ROP. V tomto článku sa pozrieme na to, aké metódy ochrany sú aplikované v najpopulárnejších distribúciách Linuxu v predvolenej konfigurácii, ako aj na vlastnosti binárnych súborov distribuovaných prostredníctvom systémov správy balíkov každého distribúcie.

CVE a bezpečnosť

Všetci sme videli články s názvami ako „Najzraniteľnejšie aplikácie roka“ alebo „Najzraniteľnejšie operačné systémy“. Zvyčajne tam uvádzajú štatistiky týkajúce sa celkového počtu záznamov o zraniteľnostiach typu CVE (Common Vulnerability and Exposures), získané z Národnej databázy zraniteľností (NVD) od NIST a ďalších zdrojov. Následne sú tieto aplikácie alebo OS hodnotené podľa počtu CVE. Bohužiaľ, aj keď sú CVE veľmi užitočné na sledovanie problémov a informovanie dodávateľov a používateľov, málo toho hovorí o reálnej bezpečnosti softvéru.

Pre príklad si vezmime celkový počet CVE za posledné štyri roky pre jadro Linuxu a päť najpopulárnejších serverových distribúcií, konkrétne Ubuntu, Debian, Red Hat Enterprise Linux a OpenSUSE.

Obr. 1

Čo nám hovorí tento graf? Znamená väčší počet CVE, že jeden distribúcia je zraniteľnejšia ako iná? Odpoveď je nie. Napríklad v tomto článku uvidíte, že v Debiane sú implementované prísnejšie ochranné mechanizmy v porovnaní s OpenSUSE alebo RedHat Linux, a predsa má Debian viac CVE. Tieto však nemusia nevyhnutne znamenať oslabenú bezpečnosť: aj prítomnosť CVE nehovorí, či je zraniteľnosť exploatovateľná. Skóre závažnosti poskytuje predstavu o tom, aká pravdepodobnosť využitia zraniteľnosti, ale nakoniec exploatovateľnosť z veľkej časti závisí od ochrany prítomnej v dotknutých systémoch, ako aj od zdrojov a schopností útočníkov. Navyše, absencia správ CVE nič nehovorí o iných nezaregistrovaných alebo neznámych zraniteľností. Rozdiel v CVE môže byť vysvetlený nie kvalitou softvéru, ale inými faktormi, vrátane zdrojov vyčlenených na testovanie alebo veľkosti používateľskej základne. V našom príklade väčší počet CVE pre Debian môže jednoducho naznačovať, že Debian poskytuje viac balíkov softvéru.

Samozrejme, systém CVE poskytuje užitočné informácie, ktoré umožňujú vytvárať príslušné ochrany. Čím lepšie rozumieme príčinám zlyhania programu, tým jednoduchšie je určiť možné spôsoby exploitácie a vyvinúť príslušné mechanizmy detekcie a reakcie. Na obr. 2 sú zobrazené kategórie zraniteľností pre všetky distribúcie za posledné štyri roky (zdroj). Hneď je jasné, že väčšina CVE patrí do nasledujúcich kategórií: odmietnutie služby (DoS), vykonanie kódu, pretečenie, poškodenie pamäte, únik (exfiltrácia) informácií a eskalácia oprávnení. Hoci mnoho CVE je zaznamenaných niekoľkokrát v rôznych kategóriách, vo všeobecnosti sa rovnaké problémy opakujú rok čo rok. V nasledujúcej časti článku zhodnotíme použitie rôznych ochranných schém na zabránenie exploitácii uvedených zraniteľností.

Obr. 2

Úlohy

V tomto článku sa zamýšľame odpovedať na nasledujúce otázky:

• Aká je bezpečnosť rôznych distribúcií Linuxu? Aké ochranné mechanizmy existujú v jadre a aplikáciách používateľského priestoru?
• Ako sa časom zmenilo prijatie ochranných mechanizmov pre rôzne distribúcie?
• Aké sú priemerné závislosti balíkov a knižníc pre každú distribúciu?
• Aké ochrany sú implementované pre každý binárny súbor?

Výber distribúcií

Zdá sa, že ťažko sa hľadá presná štatistika o inštaláciách distribúcií, pretože vo väčšine prípadov počet stiahnutí neoznačuje počet skutočných inštalácií. Napriek tomu varianty Unix tvoria väčšinu serverových systémov (na webových serveroch 69,2%, podľa štatistiky W3techs a iných zdrojov), a ich podiel neustále rastie. Preto sme sa v našom výskume zamerali na distribúcie, ktoré sú dostupné „out of the box“ na platforme Google Cloud. Konkrétne sme si vybrali nasledujúce OS:

Distribúcia/verzia
Jadro
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

Tabuľka 1

Analýza

Preskúmame predvolenú konfiguráciu jadra a vlastnosti balíkov dostupných prostredníctvom správcu balíkov každého distribúcie. Takto zvažujeme iba balíky z predvolených zrkadiel každého distribúcie a ignorujeme balíky z nestabilných repozitárov (napríklad zrkadlá 'testing' v Debian) a externé balíky (napríklad balíky Nvidia z predvolených zrkadiel). Okrem toho sa nezameriavame na používateľské kompilácie jadra alebo konfigurácie s vyššou ochranou.

Analýza konfigurácie jadra

Na analýzu sme použili skript založený na otvorenom kontrolóri kconfig. Zohľadňujeme predvolené možnosti ochrany u uvedených distribúcií a porovnávame ich so zoznamom od Projektu samoochrany jadra (KSPP). Pre každú konfiguráciu tabulka 2 popisuje požadovanú nastavenie: ihla je umiestnená pre distribúcie, ktoré zodpovedajú odporúčaniam KSSP (vysvetlenie pojmov pozri tu; v budúcich článkoch sa podrobne dozviete, ako sa mnohé z týchto metód ochrany objavili a ako hacknúť systém v ich neprítomnosti).

Vo všeobecnosti majú nové jadrá prísnejšie nastavenia hneď „z krabice“. Napríklad CentOS 6.10 a RHEL 6.10 na jadre 2.6.32 nemajú väčšinu kritických funkcií implementovaných v nových jadrách, ako sú SMAP, prísne povolenia RWX, náhodná adresácia alebo ochrana copy2usr. Je dôležité poznamenať, že mnohé z možností konfigurácie v tabuľke chýbajú v starších verziách jadra a nie sú v skutočnosti použiteľné — v tabuľke je to stále uvedené ako absencia potrebnej ochrany. Podobne, ak parameter konfigurácie chýba v tejto verzii, a pre bezpečnosť by mal byť tento parameter zakázaný, považuje sa to za rozumnú konfiguráciu.

Ešte jeden aspekt pri interpretácii výsledkov: niektoré konfigurácie jadra, ktoré zvyšujú plochu útoku, môžu súčasne slúžiť aj na zabezpečenie. Takéto príklady zahŕňajú uprobes a kprobes, jadrové moduly a BPF/eBPF. Naša odporúčanie je používať vyššie uvedené mechanizmy na zabezpečenie skutočnej ochrany, pretože nie sú triviálne na použitie a ich využitie predpokladá, že škodlivé subjekty sú už zavedené v systéme. Avšak ak sú tieto možnosti povolené, správca systému by mal aktívne sledovať zneužitia.

Pri ďalšom skúmaní záznamov tabuľky 2 vidíme, že moderné jadrá poskytujú niekoľko možností na ochranu pred zneužitím takých zraniteľností, ako sú úniky informácií a preplnenie zásobníka/hromady. Avšak si všímame, že aj najnovšie populárne distribúcie ešte neimplementovali zložitejšiu ochranu (napríklad s prístupmi grsecurity) alebo modernú ochranu proti útokom na opätovné využitie kódu (napríklad kombinácia randomizácie so schémami typu R^X pre kód). Čo je ešte horšie, aj tieto pokročilé ochranné prostriedky neposkytujú ochranu pred celým spektrom útokov. Tým pádom je pre správcov systémov mimoriadne dôležité dopĺňať rozumné konfigurácie riešeniami, ktoré ponúkajú detekciu a prevenciu exploitov v reálnom čase.

Analýza aplikácií

Nie je prekvapením, že rôzne distribúcie majú rôzne charakteristiky balíkov, nastavenia kompilácie, závislosti knižníc atď. Rozdiely existujú dokonca aj pre príbuzné distribúcie a balíky s malým počtom závislostí (napríklad coreutils v Ubuntu alebo Debian). Aby sme vyhodnotili rozdiely, stiahli sme všetky dostupné balíky, extrahovali sme ich obsah a analyzovali binárne súbory a závislosti. Pre každý balík sme sledovali iné balíky, od ktorých závisí, a pre každý binárny súbor sme sledovali jeho závislosti. V tejto časti stručne zhrnieme zistenia.

Distribúcie

Celkom sme nahrali 361 556 balíkov pre všetky distribúcie, pričom sme extrahovali len balíky zo základných zrkadiel. Ignorovali sme balíky bez spustiteľných ELF súborov, ako sú zdrojové kódy, písma a pod. Po filtrovaní ostalo 129 569 balíkov, ktoré obsahujú celkom 584 457 binárnych súborov. Rozdelenie balíkov a súborov podľa distribúcií je znázornené na obr. 3.

Obr. 3

Môžeme si všimnúť, že čím modernejšia distribúcia, tým viac balíkov a binárnych súborov v nej, čo je logické. Napriek tomu balíky Ubuntu a Debian obsahujú oveľa viac binárnych súborov (ako spustiteľných, tak dynamických modulov a knižníc) ako CentOS, SUSE a RHEL, čo potenciálne ovplyvňuje povrch útoku Ubuntu a Debian (je potrebné poznamenať, že čísla odrážajú všetky binárne súbory všetkých verzií balíka, teda niektoré súbory sa analyzujú niekoľkokrát). Je to obzvlášť dôležité, ak zohľadníme závislosti medzi balíkmi. Tak môže zraniteľnosť v binárnom súbore jedného balíka ovplyvniť mnohé časti ekosystému, ako zraniteľná knižnica môže ovplyvniť všetky binárne súbory, ktoré ju importujú. Ako východiskový bod sa pozrime na rozdelenie počtu závislostí medzi balíkmi v rôznych OS:

Obr. 4

Takmer vo všetkých distribúciách má 60% balíkov minimálne 10 závislostí. Okrem toho niektoré balíky majú počet závislostí výrazne vyšší (viac ako 100). To isté platí aj pre spätné závislosti balíkov: ako sa očakávalo, niekoľko balíkov používajú mnohé iné balíky v distribúcii, takže zraniteľnosti v týchto zopár vybraných majú vysoké riziko. Ako príklad uvádzame nasledujúcu tabuľku s 20 balíkmi s najvyšším počtom spätných závislostí v SLES, Centos 7, Debian 9 a Ubuntu 18.04 (v každej bunke je uvedený balík a počet spätných závislostí).

Tabuľka 3

Zaujímavý fakt. Hoci všetky analyzované OS sú postavené pre architektúru x86_64, a väčšina balíkov má architektúru definovanú ako x86_64 a x86, balíky často obsahujú binárne súbory pre iné architektúry, ako je znázornené na obr. 5.

Obr. 5

V nasledujúcej sekcii sa podrobnejšie pozrieme na vlastnosti analyzovaných binárnikov.

Štatistika ochrany binárnych súborov

Ako absolútny minimum je potrebné študovať základný súbor možností ochrany pre existujúce binárne súbory. Niekoľko distribúcií Linuxu sa dodáva so skriptmi, ktoré vykonávajú takéto kontroly. Napríklad v Debian/Ubuntu existuje taký skript. Tu je príklad jeho činnosti:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: áno
 Stack protected: áno
 Fortify Source functions: nie, nájdené sú len neopravené funkcie!
 Read-only relocations: áno
 Immediate binding: áno

Skript kontroluje päť ochranných funkcií:

• Position Independent Executable (PIE): určuje, či možno presunúť textový segment programu v pamäti, aby sa dosiahla náhodnosť, ak je v jadre povolený ASLR.
• Stack Protected: sú povolené ochranné kanáriky pre ochranu pred útokmi na kolíziu zásobníka.
• Fortify Source: sú nebezpečné funkcie (napríklad strcpy) nahradené ich bezpečnejšími ekvivalentmi, a kontrolované pri behu volania sú nahradené ich nekontrolovanými ekvivalentmi (napríklad memcpy namiesto __memcpy_chk).
• Read-only relocations (RELRO): sú záznamy tabuľky premiestnení označené ako „iba na čítanie“, ak boli aktivované pred začiatkom vykonávania.
• Immediate binding (okamžité viazanie): povolí linkeru runtime všetky premiestnenia pred začiatkom vykonávania programu (to je ekvivalentné úplnému RELRO).

Sú uvedené mechanizmy dostatočné? Žiaľ, nie. Sú známe spôsoby obchádzania všetkých uvedených ochrán, ale čím prísnejšia ochrana, tým vyšší je prah pre útočníka. Napríklad, metódy obchádzania RELRO sú ťažšie aplikovateľné, ak pôsobí PIE a okamžité viazanie. Rovnako úplný ASLR si vyžaduje ďalšiu prácu na vytvorení funkčného exploit. Avšak sofistikovaní útočníci sú už pripravení na takéto ochrany: ich absencia v podstate urýchli hacking. Preto je mimoriadne dôležité, aby sa tieto opatrenia považovali za nevyhnutné minimum.

Chceli sme skúmať, koľko binárnych súborov v zvažovaných distribúciách je chránených týmito a ďalšími tromi metódami:

• Nexecutabilný bit (NX) bráni vykonávaniu v akomkoľvek regióne, ktorý by nemal byť vykonávateľný, napríklad na stekovej hromade atď.
• RPATH/RUNPATH označuje cestu vykonávania, ktorú dynamický načítač používa na vyhľadanie príslušných knižníc. Prvý je povinný pre každú modernú systém: jeho absencia umožňuje útočníkom arbitrárne zapisovať payload do pamäte a vykonávať ho tak, ako je. Pre druhé nesprávne konfigurácie cesty vykonania pomáhajú zavádzať nestabilný kód, ktorý môže viesť k niekoľkým problémom (napríklad, eskalácia privilégií, ako aj iné problémy).
• Ochrana proti prekrytiu zásobníka zabezpečuje ochranu proti útokom, ktoré spôsobia, že sa zásobník prekrýva s inými oblasťami pamäte (napríklad s kopou). Vzhľadom na nedávne exploitácie zneužívajúce zraniteľnosti prekrytia kopov v systemd, považovali sme za vhodné zahrnúť tento mechanizmus do našich údajov.

Takže bez ďalších formalít, prejdeme k číslam. Tabuľky 4 a 5 obsahujú zhrnutie analýzy vykonateľných súborov a knižníc rôznych distribúcií, resp.

• Ako už bolo uvedené, ochrana NX je implementovaná vo všetkých prípadoch s niekoľkými výnimkami. Najmä je možné pozorovať o niečo nižšie jej využitie v distribúciách Ubuntu a Debian v porovnaní s CentOS, RHEL a OpenSUSE.
• Zásobníkové kanáriky sú mnoho kde absentujú, najmä v distribúciách so starými jadrami. Určitý pokrok je zaznamenaný v posledných distribúciách Centos, RHEL, Debian a Ubuntu.
• S výnimkou Debian a Ubuntu 18.04, v prípade väčšiny distribúcií je slabá podpora PIE.
• Ochrana proti prekrytiu zásobníka je slabá v OpenSUSE, Centos 7 a RHEL 7 a prakticky absentuje v ostatných.
• Všetky distribúcie s modernými jadrami majú určitú podporu RELRO, pričom vedie Ubuntu 18.04 a druhé miesto patrí Debiánu.

Ako už bolo uvedené, metriky v tejto tabuľke sú priemerné za všetky verzie binárneho súboru. Ak sa pozrieme len na posledné verzie súborov, čísla budú iné (napríklad, vid. pokrok Debian pri zavádzaní PIE). Navyše, väčšina distribúcií zvyčajne pri počítaní štatistiky kontroluje ochranu len niekoľkých funkcií v binárnom kóde, a v našej analýze je uvedené skutočné percento posilnených funkcií. Preto ak je v binárke chránených 5 z 50 funkcií, uvedieme mu hodnotenie 0,1, čo zodpovedá 10% posilnených funkcií.

Tabuľka 4. Charakteristiky ochrany pre vykonateľné súbory zobrazené na obr. 3 (implementácia príslušných funkcií v percentách z celkového počtu vykonateľných súborov)

Tabuľka 5. Vlastnosti ochrany pre knižnice zobrazené na obr. 3 (realizácia príslušných funkcií v percentách z celkového počtu knižníc)

Máme pokrok? Určite áno: je to vidieť zo štatistiky pre jednotlivé distribúcie (napríklad, Debian), ako aj z vyššie uvedených tabuliek. Ako príklad je na obr. 6 zobrazené zavádzanie ochranných mechanizmov v troch po sebe idúcich distribúciách Ubuntu LTS 5 (vynechali sme štatistiku ochrany proti kolízii zásobníka). Pozorujeme, že z verzie na verziu čoraz viac súborov podporuje zásobník kanárikov, a rovnako sa čoraz viac binárnych súborov dodáva s plnou ochranou RELRO.

Obr. 6

Žiaľ, niektoré spustiteľné súbory v rôznych distribúciách stále nemajú žiadnu z vyššie uvedených ochrán. Napríklad v Ubuntu 18.04 si môžete všimnúť binárku ngetty (náhrada getty), ako aj shelly mksh a lksh, interpret picolisp, balíky nvidia-cuda-toolkit (populárny balík pre aplikácie s GPU urýchlením, ako sú rámce strojového učenia) a klibc-utils. Podobne sa dodáva binárka mandos-client (administratívny nástroj umožňujúci automaticky reštartovať stroje so šifrovanými súborovými systémami) a rsh-redone-client (nová implementácia rsh a rlogin) bez ochrany NX, hoci majú práva SUID :(. Okrem toho v niektorých suid-binárkach chýba základná ochrana, ako sú zásobníkové kanáriky (napr. binárny súbor Xorg.wrap z balíku Xorg).

Zhrnutie a záverečné poznámky

V tomto článku sme zdôraznili niekoľko bezpečnostných vlastností moderných distribúcií Linuxu. Analýza ukázala, že v poslednej distribúcii Ubuntu LTS (18.04) je priemerne najvyššia úroveň ochrany operačného systému a aplikácií medzi distribúciami s relatívne novými jadrami, ako sú Ubuntu 14.04, 12.04 a Debian 9. Avšak posudzované distribúcie CentOS, RHEL a OpenSUSE v našich dátach predvolene poskytujú hustejší súbor balíkov, pričom najnovšie verzie (CentOS a RHEL) majú vyšší percentuálny podiel implementácie ochrany proti pretečeniu zásobníka v porovnaní s konkurentmi na báze Debiana (Debian a Ubuntu). Pri porovnávaní verzií CentOS a RedHat si všimáme veľké zlepšenia v implementácii zásobníkových kanárikov a RELRO z verzií 6 na 7, ale v priemere má CentOS viac funkcií ako RHEL. Všeobecne by sa všetkým distribúciám malo venovať zvláštna pozornosť ochrane PIE, ktorá, s výnimkou Debianu 9 a Ubuntu 18.04, bola implementovaná v menej ako 10% binárnych súborov z našich údajov.

Nakoniec je potrebné poznamenať, že aj keď sme výskum vykonali ručne, existuje množstvo bezpečnostných nástrojov (napríklad, Lynis, Tiger, Hubble), ktoré vykonávajú analýzy a pomáhajú predchádzať nebezpečným konfiguráciám. Bohužiaľ, ani silná ochrana v rozumných konfiguráciách nezaručuje absenciu exploitov. Preto sme presvedčení, že je mimoriadne dôležité zabezpečiť spoľahlivý monitoring a prevenciu útokov v reálnom čase, sústrediac sa na exploitačné vzory a ich predchádzanie.

Zdroj: habr.com