TL; DR. Selles artiklis uurime karastusskeeme, mis töötavad viie populaarse Linuxi distributsiooni puhul juba karbist välja. Iga jaoks võtsime tuuma vaikekonfiguratsiooni, laadisime kõik paketid ja analüüsisime lisatud binaarfailide turvaskeeme. Arvesse võetakse OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 ja 7, samuti Ubuntu 14.04, 12.04 ja 18.04 LTS.

Tulemused kinnitavad, et isegi põhiskeeme, nagu kanaarilindude virnastamine ja positsioonist sõltumatu kood, pole veel kõik omaks võtnud. Olukord on kompilaatorite jaoks veelgi hullem, kui rääkida haavatavuste eest, nagu stack clash, mis tõusis tähelepanu keskpunkti jaanuaris pärast avaldamist teave süsteemi haavatavuste kohta. Kuid kõik pole nii lootusetu. Märkimisväärne hulk binaarfaile rakendab põhilisi kaitsemeetodeid ja nende arv kasvab versiooniti.

Ülevaatus näitas, et OS-i ja rakenduste tasemel on kõige rohkem kaitsemeetodeid rakendatud Ubuntu 18.04-s, millele järgneb Debian 9. Teisest küljest rakendavad OpenSUSE 12.4, CentOS 7 ja RHEL 7 ka põhilisi kaitseskeeme ning kokkupõrkekaitset. kasutatakse veelgi laiemalt koos palju tihedama vaikepakettide komplektiga.

Sissejuhatus

Kvaliteetset tarkvara on raske tagada. Vaatamata suurele hulgale täiustatud tööriistadele staatilise koodi analüüsi ja dünaamilise käitusaja analüüsi jaoks ning märkimisväärsele edule kompilaatorite ja programmeerimiskeelte arendamisel, kannatab kaasaegne tarkvara endiselt turvaaukude all, mida ründajad pidevalt ära kasutavad. Olukord on veelgi hullem ökosüsteemides, mis sisaldavad pärandkoodi. Sellistel juhtudel ei seisa me silmitsi mitte ainult igavese probleemiga võimalike ärakasutatavate vigade leidmisel, vaid meid piiravad ka ranged tagasiühilduvusraamistikud, mis sageli nõuavad meilt piiratud või veelgi hullem haavatava või lollaka koodi säilitamist.

Siin tulevad mängu programmide kaitsmise või tugevdamise meetodid. Me ei saa teatud tüüpi vigu ära hoida, kuid saame ründaja elu raskemaks teha ja probleemi osaliselt lahendada, ennetades või ennetades. ärakasutamine need vead. Sellist kaitset kasutatakse kõigis kaasaegsetes operatsioonisüsteemides, kuid meetodid erinevad suuresti keerukuse, tõhususe ja jõudluse poolest: virnast kanaarilindude ja ASLR täielikule kaitsele Esimese Astme Kohus и ROP. Selles artiklis vaatleme, milliseid kaitsemeetodeid kasutatakse kõige populaarsemates Linuxi distributsioonides vaikekonfiguratsioonis, ning uurime ka iga distributsiooni paketihaldussüsteemide kaudu levitatavate binaarfailide omadusi.

CVE ja turvalisus

Oleme kõik näinud artikleid pealkirjadega "Aasta kõige haavatavamad rakendused" või "Kõige haavatavamad operatsioonisüsteemid". Tavaliselt pakuvad nad statistikat selliste haavatavuste kohta kirjete koguarvu kohta nagu CVE (tavaline haavatavus ja kokkupuuted), saadud National Vulnerability Database (NVD) pärit NIST ja muud allikad. Seejärel järjestatakse need rakendused või operatsioonisüsteemid CVE-de arvu järgi. Kahjuks, kuigi CVE-d on probleemide jälgimiseks ning tarnijate ja kasutajate teavitamiseks väga kasulikud, räägivad need tarkvara tegeliku turvalisuse kohta vähe.

Näiteks vaadake CVE-de koguarvu viimase nelja aasta jooksul Linuxi tuuma ja viie populaarseima serveridistributsiooni, nimelt Ubuntu, Debiani, Red Hat Enterprise Linuxi ja OpenSUSE jaoks.

Joon. 1

Mida see graafik meile ütleb? Kas suurem CVE-de arv tähendab, et üks distributsioon on haavatavam kui teine? Vastust pole. Näiteks näete selles artiklis, et Debianil on tugevamad turvamehhanismid võrreldes näiteks OpenSUSE või RedHat Linuxiga, kuid Debianil on rohkem CVE-sid. Kuid need ei tähenda tingimata nõrgenenud turvalisust: isegi CVE olemasolu ei näita, kas haavatavus on ära kasutatud. Raskusastmed näitavad, kuidas tõenäoliselt haavatavuse ärakasutamine, kuid lõppkokkuvõttes sõltub ekspluateeritavus suuresti mõjutatud süsteemide kaitsest ning ründajate ressurssidest ja võimalustest. Pealegi ei ütle CVE aruannete puudumine teiste kohta midagi registreerimata või teadmata haavatavused. CVE erinevus võib olla tingitud ka muudest teguritest peale tarkvara kvaliteedi, sealhulgas testimiseks eraldatud ressurssidest või kasutajabaasi suurusest. Meie näites võib Debiani suurem CVE-de arv lihtsalt viidata sellele, et Debian tarnib rohkem tarkvarapakette.

Loomulikult pakub CVE süsteem kasulikku teavet, mis võimaldab luua sobivaid kaitseid. Mida paremini mõistame programmi ebaõnnestumise põhjuseid, seda lihtsam on tuvastada võimalikke kasutusviise ja välja töötada sobivad mehhanismid. avastamine ja reageerimine. Joonisel fig. 2 näitab haavatavuste kategooriaid kõigi distributsioonide jaoks viimase nelja aasta jooksul (allikas). Kohe on selge, et enamik CVE-sid jaguneb järgmistesse kategooriatesse: teenuse keelamine (DoS), koodi täitmine, ületäitumine, mälu rikkumine, teabe leke (eksfiltratsioon) ja privileegide eskalatsioon. Kuigi paljusid CVE-sid arvestatakse erinevates kategooriates mitu korda, püsivad üldiselt aasta-aastalt samad probleemid. Artikli järgmises osas hindame erinevate kaitseskeemide kasutamist, et vältida nende haavatavuste ärakasutamist.

Joon. 2

ülesanded

Käesolevas artiklis tahame vastata järgmistele küsimustele:

• Mis on erinevate Linuxi distributsioonide turvalisus? Millised kaitsemehhanismid on kerneli ja kasutajaruumi rakendustes?
• Kuidas on turbemehhanismide kasutuselevõtt aja jooksul distributsioonide lõikes muutunud?
• Millised on pakettide ja teekide keskmised sõltuvused iga distributsiooni puhul?
• Milliseid kaitsemeetmeid rakendatakse iga kahendfaili jaoks?

Distributsioonide valik

Selgub, et täpset statistikat levipaigaldiste kohta on raske leida, kuna enamasti ei näita allalaadimiste arv tegelike installimiste arvu. Kuid Unixi variandid moodustavad enamiku serverisüsteemidest (veebiserverites 69,2%, statistika W3techs ja muud allikad) ning nende osakaal kasvab pidevalt. Seega keskendusime oma uurimistöös platvormil karbist väljas saadaolevatele distributsioonidele Google Cloud. Eelkõige valisime järgmise OS-i:

Levitamine/versioon
Kernel
Ehitada

OpenSUSE 12.4
4.12.14-95.3-vaikimisi
#1 SMP kolmapäev 5. detsember 06:00:48 UTC 2018 (63a8d29)

Debian 9 (venitav)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)

6.10 CentOS
2.6.32-754.10.1.el6.x86_64
#1 SMP T 15. jaanuar 17:07:28 UTC 2019

7 CentOS
3.10.0-957.5.1.el7.x86_64
#1 SMP R 1. veebruar 14:54:57 UTC 2019

Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP kolmapäev, 21. november 15:08:21 EST 2018

Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Neljap 15. november 17:36:42 UTC 2018

Ubuntu 14.04 (usaldusväärne Tahr)
4.4.0–140-üldine

#166~14.04.1-Ubuntu SMP L 17. november 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP R 7. detsember 09:59:47 UTC 2018

Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27 – Ubuntu SMP neljap 6. detsember 18:27:01 UTC 2018

Tabel 1

Analüüs

Uurime kerneli vaikekonfiguratsiooni ja iga distributsiooni paketihalduri kaudu saadaolevate pakettide omadusi. Seega võtame arvesse ainult iga distributsiooni vaikepeeglite pakette, ignoreerides pakette ebastabiilsetest hoidlatest (nt Debiani testimispeeglid) ja kolmandate osapoolte pakette (nt Nvidia pakette standardsetest peeglitest). Lisaks ei võta me arvesse kohandatud kerneli kompilatsioone ega turbega tugevdatud konfiguratsioone.

Kerneli konfiguratsiooni analüüs

Rakendasime analüüsiskripti, mis põhineb tasuta kconfigi kontrollija. Vaatame nimeliste distributsioonide kasutusvalmis kaitseparameetreid ja võrdleme neid loendiga Põhiline enesekaitseprojekt (KSPP). Iga konfiguratsioonivaliku jaoks kirjeldab tabel 2 soovitud seadistust: märkeruut on mõeldud distributsioonide jaoks, mis vastavad KSSP soovitustele (terminite selgitusi vt allpool). siin; Edaspidistes artiklites selgitame, kui paljud neist turvameetoditest tekkisid ja kuidas nende puudumisel süsteemi häkkida).

Üldiselt on uutel tuumadel karbist väljas rangemad sätted. Näiteks CentOS 6.10 ja RHEL 6.10 2.6.32 tuumal puuduvad enamik kriitilistest funktsioonidest, mis on rakendatud uuemates tuumades, näiteks SMAP, ranged RWX-load, aadresside randomiseerimine või copy2usr-kaitse. Tuleb märkida, et paljud tabelis toodud konfiguratsioonisuvandid ei ole kerneli vanemates versioonides saadaval ega ole tegelikkuses rakendatavad – see on tabelis siiski märgitud nõuetekohase kaitse puudumisena. Samuti, kui konfiguratsioonisuvand antud versioonis puudub ja turvalisus nõuab selle valiku keelamist, peetakse seda mõistlikuks konfiguratsiooniks.

Veel üks punkt, mida tulemuste tõlgendamisel arvestada: turvalisuse tagamiseks saab kasutada ka mõnda tuuma konfiguratsiooni, mis suurendab rünnakupinda. Selliste näidete hulka kuuluvad uprobes ja kprobes, kerneli moodulid ja BPF/eBPF. Meie soovitus on kasutada ülaltoodud mehhanisme tõelise kaitse tagamiseks, kuna nende kasutamine ei ole triviaalne ja nende ärakasutamine eeldab, et pahatahtlikud osalejad on süsteemis juba tugipunkti loonud. Kuid kui need valikud on lubatud, peab süsteemiadministraator aktiivselt jälgima kuritarvitamist.

Vaadates tabeli 2 kirjeid, näeme, et kaasaegsed tuumad pakuvad mitmeid võimalusi, kuidas kaitsta haavatavuste, nagu teabelekke ja virna/kuhja ületäitumise eest. Siiski märkame, et isegi kõige uuemad populaarsed distributsioonid ei ole veel rakendanud keerukamat kaitset (näiteks plaastritega grturvalisus) või kaasaegne kaitse koodi taaskasutamise rünnakute vastu (nt. randomiseerimise kombinatsioon skeemidega nagu R^X koodi jaoks). Asja teeb hullemaks see, et isegi need arenenumad kaitsemehhanismid ei kaitse kõigi rünnakute eest. Seetõttu on süsteemiadministraatorite jaoks ülioluline täiendada nutikaid konfiguratsioone lahendustega, mis pakuvad käitusaegse ärakasutamise tuvastamist ja ennetamist.

Rakenduse analüüs

Pole üllatav, et erinevatel distributsioonidel on erinevad pakettide omadused, kompileerimisvalikud, teegi sõltuvused jne. Erinevused eksisteerivad isegi seotud distributsioonid ja paketid, millel on vähe sõltuvusi (näiteks coreutils Ubuntu või Debiani puhul). Erinevuste hindamiseks laadisime alla kõik saadaolevad paketid, ekstraheerisime nende sisu ning analüüsisime binaarfaile ja sõltuvusi. Iga paketi puhul jälgisime teisi pakette, millest see sõltub, ja iga binaari puhul selle sõltuvusi. Selles osas teeme järeldused lühidalt kokku.

distributsioonid

Kokku laadisime kõigi distributsioonide jaoks alla 361 556 paketti, eraldades vaikepeeglitest ainult paketid. Eirasime ELF-i käivitatavate failideta pakette, nagu allikad, fondid jne. Pärast filtreerimist jäi järele 129 569 paketti, mis sisaldasid kokku 584 457 binaarfaili. Pakettide ja failide jaotus distributsioonide vahel on näidatud joonisel fig. 3.

Joon. 3

Võite märgata, et mida kaasaegsem on distributsioon, seda rohkem pakette ja binaarfaile see sisaldab, mis on loogiline. Ubuntu ja Debiani paketid sisaldavad aga palju rohkem binaarfaile (nii käivitatavaid kui ka dünaamilisi mooduleid ja teeke) kui CentOS, SUSE ja RHEL, mis potentsiaalselt mõjutab Ubuntu ja Debiani ründepinda (tuleb märkida, et numbrid kajastavad kõigi versioonide kõiki binaarfaile pakett, st mõnda faili analüüsitakse mitu korda). See on eriti oluline, kui arvestada pakettidevahelisi sõltuvusi. Seega võib haavatavus ühes paketti binaarfailis mõjutada paljusid ökosüsteemi osi, nagu haavatav teek võib mõjutada kõiki binaarfaile, mis seda impordivad. Alustuseks vaatame sõltuvuste arvu jaotust pakettide vahel erinevates operatsioonisüsteemides:

Joon. 4

Peaaegu kõigis distributsioonides on 60% pakettidest vähemalt 10 sõltuvust. Lisaks on osadel pakettidel oluliselt suurem arv sõltuvusi (üle 100). Sama kehtib ka pöördpakettide sõltuvuste kohta: ootuspäraselt kasutavad paljud teised distributsioonis olevad paketid mõnda paketti, seega on nende väheste valitud haavatavused kõrge riskiga. Näitena on järgmises tabelis loetletud 20 paketti, millel on maksimaalne pöördsõltuvuste arv SLES-is, Centos 7-s, Debian 9-s ja Ubuntu 18.04-s (iga lahter näitab paketti ja pöördsõltuvuste arvu).

Tabel 3

Huvitav fakt. Kuigi kõik analüüsitud OS-id on loodud x86_64 arhitektuuri jaoks ja enamiku pakettide arhitektuur on määratletud kui x86_64 ja x86, sisaldavad paketid sageli teiste arhitektuuride jaoks mõeldud binaarfaile, nagu on näidatud joonisel 5. XNUMX.

Joon. 5

Järgmises osas süveneme analüüsitud kahendfailide omadustesse.

Binaarfailide kaitse statistika

Vähemalt peate oma olemasolevate binaarfailide jaoks uurima põhilisi turvavalikuid. Mitmed Linuxi distributsioonid sisaldavad selliseid kontrolle teostavaid skripte. Näiteks Debian/Ubuntu on selline skript olemas. Siin on näide tema tööst:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

Skript kontrollib viis kaitsefunktsioonid:

• Positsioonist sõltumatu käivitatav (PIE): näitab, kas programmi tekstiosa saab mällu teisaldada, et saavutada randomiseerimine, kui kernelis on lubatud ASLR.
• Virnaga kaitstud: kas virna kanaaridel on lubatud kaitsta virna kokkupõrke rünnakute eest.
• Fortify Source: kas ebaturvalised funktsioonid (nt strcpy) asendatakse nende turvalisemate vastetega ja käitusajal kontrollitud kõned nende kontrollimata vastetega (näiteks memcpy __memcpy_chk asemel).
• Kirjutuskaitstud ümberpaigutused (RELRO): kas ümberpaigutamise tabeli kirjed märgitakse kirjutuskaitstuks, kui need käivitatakse enne täitmise algust.
• Kohene sidumine: kas käitusaegne linker lubab enne programmi käivitamist kõik liigutused (see võrdub täieliku RELRO-ga).

Kas ülaltoodud mehhanismidest piisab? Kahjuks ei. Teada on viise, kuidas kõigist ülaltoodud kaitsetest mööda minna, kuid mida karmim on kaitse, seda kõrgem on latt ründaja jaoks. Näiteks, RELRO möödaviigumeetodid raskem rakendada, kui kehtivad PIE ja kohene sidumine. Täielik ASLR nõuab samuti täiendavat tööd, et luua töötav ärakasutamine. Kuid kogenud ründajad on juba valmis sellistele kaitsemeetmetele vastama: nende puudumine kiirendab oluliselt häkkimist. Seetõttu on oluline neid meetmeid vajalikuks pidada minimaalselt.

Tahtsime uurida, kui palju binaarfaile kõnealustes distributsioonides on kaitstud nende ja kolme muu meetodiga:

• Käivitamatu bitt (NX) takistab käivitamist mis tahes piirkonnas, mis ei tohiks olla käivitatav, näiteks virnahunnikus jne.
• RPATH/RUNPATH tähistab täitmisteed, mida dünaamiline laadur kasutab sobivate teekide leidmiseks. Esimene on kohustuslik iga kaasaegse süsteemi jaoks: selle puudumine võimaldab ründajatel kasuliku koormuse meelevaldselt mällu kirjutada ja seda nii nagu on. Teiseks aitavad valed täitmistee konfiguratsioonid sisestada ebausaldusväärse koodi, mis võib põhjustada mitmeid probleeme (nt. privileegide eskalatsioon ning muud probleemid).
• Viru kokkupõrkekaitse pakub kaitset rünnakute eest, mis põhjustavad virna kattumist teiste mälupiirkondadega (nt hunnik). Arvestades hiljutist kuritarvitamist süsteemse hunniku kokkupõrke haavatavused, pidasime sobivaks lisada see mehhanism meie andmekogumisse.

Nii et ilma pikema jututa asume numbrite juurde. Tabelid 4 ja 5 sisaldavad vastavalt erinevate distributsioonide käivitatavate failide ja teekide analüüsi kokkuvõtet.

• Nagu näete, rakendatakse NX-kaitset kõikjal, harvade eranditega. Eelkõige võib märkida selle veidi väiksemat kasutamist Ubuntu ja Debiani distributsioonides võrreldes CentOS-i, RHELi ja OpenSUSE-ga.
• Pinnakanaarid on paljudes kohtades puudu, eriti vanemate tuumadega distributsioonides. Teatavat edu on näha Centose, RHELi, Debiani ja Ubuntu uusimates distributsioonides.
• Välja arvatud Debian ja Ubuntu 18.04, on enamikul distributsioonidel halb PIE tugi.
• Pinna kokkupõrkekaitse on OpenSUSE-s, Centos 7-s ja RHEL 7-s nõrk ning teistes praktiliselt olematu.
• Kõik moodsate tuumadega distributsioonid toetavad RELRO-d, Ubuntu 18.04 juhib teed ja Debian on teisel kohal.

Nagu juba mainitud, on selle tabeli mõõdikud binaarfaili kõigi versioonide keskmised. Kui vaatate ainult failide uusimaid versioone, on numbrid erinevad (näiteks vt Debiani edu PIE juurutamisel). Veelgi enam, enamik distributsioone testib statistika arvutamisel tavaliselt ainult mõne kahendfaili funktsiooni turvalisust, kuid meie analüüs näitab kõvastunud funktsioonide tegelikku protsenti. Seega, kui 5-st funktsioonist 50 on kahendkoodis kaitstud, anname sellele hindeks 0,1, mis vastab 10% tugevdatavatest funktsioonidest.

Tabel 4. Joonisel fig. 3 (asjakohaste funktsioonide rakendamine protsendina käivitatavate failide koguarvust)

Tabel 5. Joonisel fig. 3 (asjakohaste funktsioonide rakendamine protsendina raamatukogude koguarvust)

Kas on siis edusamme? Kindlasti on: seda võib näha üksikute jaotuste statistikast (näiteks Debian), samuti ülaltoodud tabelitest. Näitena joonisel fig. Joonisel 6 on kujutatud kaitsemehhanismide rakendamist kolmes järjestikuses Ubuntu LTS 5 distributsioonis (oleme välja jätnud virna kokkupõrkekaitse statistika). Märkame, et versioonist versioonini toetab üha rohkem faile virna kanaari, samuti tarnitakse üha rohkem binaarfaile täieliku RELRO kaitsega.

Joon. 6

Kahjuks ei ole paljudel erinevates distributsioonides olevatel käivitatavatel failidel ikka veel ühtegi ülaltoodud kaitset. Näiteks Ubuntu 18.04 vaadates märkate ngetty binaarfaili (getty asendus), aga ka mksh ja lksh kestasid, picolisp interpretaatorit, pakette nvidia-cuda-toolkit (populaarne pakett GPU-kiirendusega rakenduste jaoks nagu masinõppe raamistikud) ja klibc -utils. Samamoodi tarnitakse mandos-kliendi binaarfail (haldustööriist, mis võimaldab automaatselt taaskäivitada krüptitud failisüsteemidega masinaid) ja rsh-redone-client (rsh-i ja rlogin-i taasrakendus) ilma NX-kaitseta, kuigi neil on SUID-õigused: (. Samuti puudub mitmel suid binaarfailil põhiline kaitse, näiteks virna kanaarid (nt Xorgi paketist pärit kahendfail Xorg.wrap).

Kokkuvõte ja lõppmärkused

Selles artiklis oleme esile tõstnud mitmeid kaasaegsete Linuxi distributsioonide turvafunktsioone. Analüüs näitas, et uusim Ubuntu LTS-i distributsioon (18.04) rakendab suhteliselt uute tuumadega distributsioonide hulgas, nagu Ubuntu 14.04, 12.04 ja Debian 9, keskmiselt tugevaimat OS-i ja rakenduste tasemel kaitset. Uuritud distributsioonid on aga CentOS, RHEL ja Vaikimisi toodavad OpenSUSE meie komplektis tihedamat pakettide komplekti ning viimastes versioonides (CentOS ja RHEL) on neil suurem protsent virna kokkupõrkekaitset võrreldes Debianil põhinevate konkurentidega (Debian ja Ubuntu). Võrreldes CentOS-i ja RedHati versioone, märkame suuri täiustusi stack canaries ja RELRO juurutamisel versioonidest 6 kuni 7, kuid keskmiselt on CentOS-is rakendatud rohkem funktsioone kui RHEL-is. Üldiselt peaksid kõik distributsioonid pöörama erilist tähelepanu PIE kaitsele, mis, välja arvatud Debian 9 ja Ubuntu 18.04, on rakendatud vähem kui 10% meie andmestiku binaarfailidest.

Lõpuks tuleb märkida, et kuigi me viisime uuringu läbi käsitsi, on saadaval palju turvatööriistu (nt. Lynis, Tiiger, Hubble'i), mis teostavad analüüsi ja aitavad vältida ohtlikke konfiguratsioone. Kahjuks ei taga isegi tugev kaitse mõistlikes konfiguratsioonides ärakasutamise puudumist. Seetõttu usume kindlalt, et selle tagamine on ülioluline rünnakute usaldusväärne jälgimine ja ennetamine reaalajas, keskendudes ärakasutamise mudelitele ja nende ärahoidmisele.

Allikas: www.habr.com