TL;DR. Selles artiklis uurime kaitse skeeme (hardening schemes), mis vaikimisi töötavad viies populaarses Linuxi jaotuses. Igaühe jaoks võtsime vaikimisi tuuma konfiguratsiooni, laadisime alla kõik paketid ja analüüsisime kaitse skeeme sisemistes binaarfailides. Arvustatakse jaotusi 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õhikaitse skeeme, nagu virnastamis-kanariesed ja positsioonist sõltumatu kood, ei kasutata veel laialdaselt. Olukord on veelgi halvem kompilaatorite seas, kui räägime haavatavustest, nagu virnastamise kokkupõrge (stack clash), mis tõusid esile jaanuaris, pärast info avaldamist haavatavuste kohta systemd. Kuid olukord ei ole nii lootusetu. Suurtes osades binaarfaile on rakendatud põhilised kaitsemeetodid ja nende arv kasvab versioonist versiooni.

Kontroll näitas, et kõige rohkem kaitsemeetodeid on rakendatud Ubuntu 18.04 OS-i ja rakenduste tasemel, sellele järgneb Debian 9. Teiselt poolt on OpenSUSE 12.4, CentOS 7 ja RHEL 7 samuti rakendatud põhikaitseskeeme, samas kui virnastamise konflikti kaitse on rakendatud laiemalt palju tihedama vaikimisi pakettide komplektiga.

Sissejuhatus

Tarkvara kvaliteedi tagamine on keeruline. Hoolimata suurest hulgast arenenud utiliitidest staatilise koodi analüüsi ja dünaamilise käitamise analüüsi jaoks ning märkimisväärsest edusammust kompilaatorite ja programmeerimiskeelte arendamises, kannatab kaasaegne tarkvara endiselt haavatavuste all, mida kurjategijad pidevalt ära kasutavad. Olukord on veel hullem ökosüsteemides, mis sisaldavad vananenud koodi. Sel juhul seisame silmitsi mitte ainult igavese probleemiga, et leida võimalikke haavatavaid vigu, vaid oleme ka rangete tagasipöördumise ühilduvusraamide tõttu piiratud, mis sageli nõuavad vananenud, ja veel hullem, haavatava või tõrkuva koodi säilitamist.

Siin tulevad mängu kaitse- või tugevdamismeetodid (hardening). Mõningaid vigu me ei suuda ennetada, kuid saame muuta kurjategija elu keerulisemaks ja probleemid osaliselt lahendada, ennetades või takistades haavatavuse neid vigu. Sellist kaitset kasutatakse kõikides kaasaegsetes operatsioonisüsteemides, kuid meetodid erinevad oluliselt keerukuse, efektiivsuse ja jõudluse poolest: alates virnastamiskanareid (stack canaries) ja ASLR kuni täieõiguslike kaitseteni CFI ja ROP. Selles artiklis vaatleme, millised kaitsemeetodid on rakendatud kõige populaarsemates Linuxi distributsioonides vaikeseadistustes, samuti uurime binaaride omadusi, mis levivad iga distributsiooni pakihaldussüsteemide kaudu.

CVE ja turvalisus

Me oleme kõik näinud artikleid pealkirjadega nagu «Aasta kõige haavatavamad rakendused» või «Aasta kõige haavatavamad operatsioonisüsteemid». Tavaliselt sisaldavad need statistikat, mis käsitleb üldiste haavatavuste arvu tüüpi CVE (Common Vulnerability and Exposures), mis on saadud Rahvuslikust haavatavuste andmebaasist (NVD) alates NIST ja teistest allikatest. Edasi on need rakendused või operatsioonisüsteemid järjestatud CVE arvu järgi. Kahjuks, kuigi CVE-d on hädavajalikud probleemide jälgimiseks ja tarnijate ning kasutajate teavitamiseks, ütlevad need vähe tarkvara tegeliku turvalisuse kohta.

Näiteks vaatame viimase nelja aasta jooksul Linuxi kärje ja viie kõige populaarsema serveri jaotuse, sealhulgas Ubuntu, Debian, Red Hat Enterprise Linux ja OpenSUSE, koguarvu CVE-sid.

Joon. 1

Mida ütleb meile see diagramm? Kas suurem CVE arv tähendab, et üks jaotus on teistega võrreldes haavatavam? Vastus on ei. Näiteks näete selles artiklis, et Debianis on rakendatud rangemaid kaitsemehhanisme võrreldes näiteks OpenSUSE või RedHat Linuxiga, ja siiski on Debiani CVE arv suurem. Kuid need ei tähenda tingimata nõrgenenud turvalisust: isegi CVE olemasolu ei näita, kas haavatavus on kasutatav. Tõsiduse punktid annavad aimu, kui tõenäoline haavatavuste kasutamine, kuid lõppkokkuvõttes sõltub ära kasutatavus suuresti kahjustatud süsteemides olemasolevast kaitsetasemest ning ka ründajate ressurssidest ja võimalustest. Lisaks ei ütle CVE aruanete puudumine midagi teiste registreerimata või teadmata haavatavuste kohta. CVE erinevus ei pruugi olla tingitud tarkvara kvaliteedist, vaid muudest teguritest, sealhulgas katsetamiseks eraldatud ressurssidest või kasutajabaasi suurusest. Meie näites võib suurem CVE arv Debianis lihtsalt tähendada, et Debian pakub rohkem tarkvarapakette.

Muidugi, CVE süsteem annab kasulikku teavet, mis võimaldab luua vastavaid kaitsemehhanisme. Mida paremini me mõistame programmi rikke põhjuseid, seda lihtsam on määrata võimalikke ära kasutamise viise ja arendada vastavaid tuvastamise ja reageerimisemehhanisme. Joonisel 2 on näidatud haavatavuste kategooriad kõikides distributsioonides viimase nelja aasta jooksul (allikas). Selgelt on näha, et enamik CVE-d kategooriatesse kuulub järgmistele: teenuse katkestamine (DoS), koodi täitmine, ülevool, mälukahjustus, teabe leke (ekstraktsioon) ja privileegide eskaleerimine. Kuigi palju CVE-sid on loetletud mitmes kategoorias, jäävad üldiselt samad probleemid aastast aastasse. Järgmises artikli osas hindame erinevate kaitsemeetodite kasutamist nende haavatavuste ärahoidmiseks.

Joon. 2

Ülesanded

Selles artiklis kavatseme vastata järgmistele küsimustele:

• Milline on erinevate Linuxi jaotuste turvalisus? Millised kaitsemehhanismid eksisteerivad tuumas ja kasutajaruumi rakendustes?
• Kuidas on ajas muutunud kaitsemehhanismide vastuvõtmine erinevates jaotustes?
• Millised on keskmised pakettide ja raamatukogude sõltuvused igas jaotuses?
• Millised kaitsed on rakendatud iga binaari jaoks?

Jaotuste valik

Tundub, et täpset statistikat jaotuste installide kohta on keeruline leida, kuna enamikul juhtudel allalaadimiste arv ei näita tegelike installide arvu. Sellegipoolest moodustavad Unix variandid enamus serverisüsteeme (veebiserverites 69,2%, vastavalt statistikat W3techs ja teistele allikatele), ja nende osakaal kasvab pidevalt. Seetõttu keskendusime oma uuringus väljaannetele, mis on saadaval väljaanna platvormil Google Cloud. Eelkõige valisime järgmised opsüsteemid:

Jaotus/versioon
Tuuma
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

Tabel 1

Analüüs

Uurime vaikimisi kernel'i konfiguratsiooni ja iga distributsiooni paketihalduri kaudu saadaval olevate pakettide omadusi. Seega vaatleme ainult iga distributsiooni vaikimisi peegeldustest saadud pakette, jättes tähelepanuta ebatäiuslikest hoidlatest (nt Debian'i 'testing' peeglid) ja kolmandate osapoolte pakette (nt Nvidia pakette vaikimisi peeglitest). Lisaks ei käsitle me kohandatud kernel'i komp ileerimisi või kõrgendatud kaitsega konfiguratsioone.

Kernel'i konfiguratsiooni analüüs

Me rakendasime analüüsiskripti, mis põhineb avatud kconfig'i kontrollijal. Vaatame nendest distributsioonidest välja toodud vaikimisi kaitseparameetreid ja võrdleme neid Kernel'i enesekaitse projekti (KSPP) loendiga. Iga konfiguratsiooniparameetri jaoks kirjeldab tabel 2 soovitud seadet: linnuke on neil distributsioonidel, mis vastavad KSSP soovitustele (terminite selgitamise kohta vaata siit; tulevastes artiklites räägime, kuidas paljusid neist kaitsemeetoditest saavutati ja kuidas süsteemi nende puudumisel häkkida).

Uutes tuumades on üldiselt rangemad vaikeseaded. Näiteks CentOS 6.10 ja RHEL 6.10 tuumal, mis põhineb 2.6.32, puuduvad enamiku kriitiliste funktsioonide toed, mis on rakendatud uutest tuumadest, nagu SMAP, ranged RWX õigused, aadresside randomiseerimine või copy2usr kaitse. Tuleb märkida, et paljusid konfigureerimisvõimalusi tabelis ei leidu vanemates tuumaversioonides ja need ei ole tegelikult rakendatavad — tabelis on see ikka näidatud kui piisava kaitse puudumine. Samuti, kui konfigureerimisparameeter puudub sellesse versiooni, ja selle parameetri keelamine on vajalik, peetakse seda mõistlikuks konfiguratsiooniks.

Veel on oluline arvestada tulemuste tõlgendamisel: mõned tuumakonfiguratsioonid, mis suurendavad rünnakupinda, võivad samal ajal olla kasulikud ka ohutusele. Näiteks on sellised eeskujud uprobed ja kprobed, tuumamoodulid ja BPF/eBPF. Meie soovitus on kasutada ülaltoodud mehhanisme tõhusa kaitse tagamiseks, kuna need pole triviaalsete kasutamiseks ja nende ärakasutamine tähendab, et pahatahtlikud osalised on juba süsteemis juurdunud. Kuid kui need valikud on sisse lülitatud, peab süsteemi administraator aktiivselt jälgima väärkasutusi.

Uurides edasi tabeli 2 kirjeid, näeme, et tänapäevased tuumad pakuvad mitmeid võimalusi selliste haavatavuste ärahoidmiseks nagu teabe leke ja virna/ribaga ülevool. Siiski märkame, et isegi kõige uuemad populaarsed jaoturid ei ole veel rakendanud keerukamat kaitset (näiteks plaastrid grsecurity) ega ka kaasaegset kaitset koodi uuesti kasutamise rünnakute vastu (näiteks koodirandomimise kombineerimine R^X-skeemidega). Miski halvem, isegi need arenenud kaitsemeetmed ei kaitse kõigi rünnakute spektri eest. Seetõttu on süsteemi administraatoritele äärmiselt oluline täiendada mõistlikke konfiguratsioone lahendustega, mis pakuvad ekspluateerimise avastamist ja tõkestamist käitamisaja jooksul.

Rakenduste analüüs

Pole üllatav, et erinevatel distributsioonidel on erinevad pakettide omadused, kompileerimisvalikud, teekide sõltuvused jne. Erinevused on olemas isegi sugulaste distributsioonide ja pakettide puhul, millel on vähem sõltuvusi (nt coreutils Ubuntu või Debianis). Erinevuste hindamiseks laadisime alla kõik saadaval olevad paketid, ekstraktisime nende sisu ja analüüsisime binaarfailid ja sõltuvused. Iga paketi puhul jälgisime teisi pakette, millele see toetub, ning iga binaari puhul jälgisime selle sõltuvusi. Käesolevas jaos esitame kokkuvõtte tulemused.

Distributsioonid

Kokku on me laaditud 361 556 paketti kõikide distributsioonide jaoks, valides ainult vaikimisi peeglitelt saadud paketid. Me ignoreerisime pakette, mis ei sisaldanud ELF täidetavaid faile, nagu lähtekoodid, fondid jne. Pärast filtreerimist jäi järele 129 569 paketti, mis sisaldavad kokku 584 457 binaarfaili. Pakettide ja failide jaotus distributsioonide vahel on toodud joonisel 3.

Joon. 3

On märgata, et mida uuem on jaotamine, seda rohkem on selles pakette ja binaarfaile, mis on loogiline. Samas sisaldavad Ubuntu ja Debian paketid palju rohkem binaarfaile (n nii käivitatavaid kui ka dünaamilisi mooduleid ja raamatukogusid) kui CentOS, SUSE ja RHEL, mis võib potentsiaalselt mõjutada Ubuntu ja Debian rünnakupinda (tuleb märkida, et numbrid peegeldavad kõiki pakettide versioonide binaarfaile, st mõned failid analüüsitakse mitu korda). See on eriti oluline, arvestades pakettide vahelisi sõltuvusi. Seega võib ühe paketi binaarfailides esinev haavatavus mõjutada paljusid osasid ökosüsteemist, nagu haavatav raamatukogu võib mõjutada kõiki binaarfaile, mis seda importivad. Võrdluseks vaatame sõltuvuste jaotust erinevate operatsioonisüsteemide pakettides:

Joon. 4

Peaaegu kõikides distributsioonides on 60% pakettidest vähemalt 10 sõltuvust. Lisaks on mõne paketi sõltuvuste arv märkimisväärselt suurem (üle 100). Sama kehtib ka pakettide tagas sõltuvuste kohta: nagu oodatud, kasutatakse mitmeid pakette paljude teiste pakettide poolt distributsioonis, seega on nende väheste valitud pakettide haavatavustel kõrge risk. Näiteks loetletakse alltoodud tabelis 20 paketti, millel on maksimaalne tagas sõltuvuste arv SLES, CentOS 7, Debian 9 ja Ubuntu 18.04 (iga lahtri sees näidatakse paketti ja tagas sõltuvuste arvu).

Tabel 3

Huvitav fakt. Kuigi kõik analüüsitud operatsioonisüsteemid on loodud arhitektuurile x86_64, ja enamikul pakettidest on arhitektuur määratud kui x86_64 ja x86, sisaldavad paketid sageli binaarfailide eksemplare ka teistele arhitektuuridele, nagu näidatud joonisel 5.

Joon. 5

Järgmises jaotises uurime analüüsitud binaarfailide omadusi.

Binaarfailide kaitset statistika

Aluseks peate uurima põhikomplekti kaitsevariantes olemasolevatele binaarfailidele. Mitmed Linuxi distributsioonid tulevad skriptidega, mis teostavad selliseid kontrollimise. Näiteks Debianis/Ubuntu on olemas selline skript. Siin on näide sellest, kuidas see töötab:

$ hardening-check $(which docker)
/usr/bin/docker:
 Asendi Indipendentne Täidetav: jah
 Kaitsmega Virn: jah
 Fortify Source funktsioonid: ei, ainult kaitsetud funktsioonid leitud!
 Kirja ainult lugemiseks ümberpaigutamiseks: jah
 Kohene allkiri: jah

Skript kontrollib viite kaitsefunktsiooni:

• Asendi Indipendentne Täidetav (PIE): näitab, kas programmi tekstiosa saab mälus ümber paigutada, et saavutada randomiseerimine, kui kernelis on aktiveeritud ASLR.
• Kaitstud Virn: kas virnapausid on aktiveeritud kaitseks virna kokkupõrke rünnakute eest.
• Fortify Source: kas ohtlikud funktsioonid (nt strcpy) asendatakse nende ohutumate kolleegide, ning käitumisaegsete kontrollide asemel kasutatakse nende mitte-kontrollitavaid vastendeid (nt memcpy, mitte __memcpy_chk).
• Ainult lugemiseks ümberpaigutamine (RELRO): kas ümberpaigutamise tabeli kirjed on märgitud 'ainult lugemiseks', kui need on aktiveeritud enne käivitust.
• Otsene sidumine (Immediate binding): kas toimub igasuguste liigutuste lubamine enne programmi käivitamist (see on võrreldav täieliku RELRO-ga).

Kas eespool loetletud mehhanismid on piisavad? Kahjuks ei. On teada viise, kuidas kõiki eespool mainitud kaitsemehhanisme ületada, kuid mida rangem on kaitse, seda kõrgem on riba ründajale. Näiteks on RELRO ületamise meetodid raske rakendada, kui kehtib PIE ja otsene sidumine. Samuti eeldab täielik ASLR täiendavat tööd töötava ekspluateerimise loomisel. Kuid peened küberkurjategijad on juba valmis selliste kaitsete vastu: nende puudumine kiirendab põhiliselt rünnakut. Seega on äärmiselt oluline, et neid meetmeid käsitletaks kui hädavajalikke. vähemalt.

Soovisime uurida, kui palju binaarfailide osas, mida uuritakse distributsioonides, on kaitstud nende ja veel kolme meetodiga:

• Käivitamatu bit (NX) takistab käivitamist igas piirkonnas, mis ei tohiks olla käivitatav, näiteks virnas, stekis jne.
• RPATH/RUNPATH tähistab teed, mida dünaamiline laadija kasutab vastavate teekeede leidmiseks. Esimene on kohustuslik iga tänapäeva süsteemi jaoks: selle puudumine võimaldab ründajatel suvaliselt koormust mälu laadida ja seda otse täita. Teisel juhul aitavad vale konfiguratsioonid täitmisrada sisse tuua ebausaldusväärset koodi, mis võib põhjustada mitmeid probleeme (näiteks priviiigede eskaleerimine, samuti teised probleemid).
• Stack collision protection kaitseb rünnakute eest, mis sunnivad stack'i kattuma teiste mälu aladega (nt kuhja). Arvestades hiljutisi eksploite, mis ära kasutavad kuhja kokkupõrke haavatavusi systemd-s, leidsime, et on kohane see mehhanism meie andmetesse lisada.

Nii et, edasi liikudes, vaatame numbreid. Tabelites 4 ja 5 on esitatud erinevate jaotuste teostatavate failide ja raamatukogude analüüsi koondamine.

• Nagu võib märgata, on NX kaitse ellu viidud igal pool, välja arvatud mõned erandid. Eriti tuleks märkida selle madalamat kasutamist Ubuntu ja Debian jaotustes võrreldes CentOS, RHEL ja OpenSUSE-ga.
• Stack canaries are often absent, especially in distributions with older kernels. Some progress can be seen in recent versions of CentOS, RHEL, Debian, and Ubuntu.
• With the exception of Debian and Ubuntu 18.04, most distributions have poor support for PIE.
• Protection against stack collisions is poorly implemented in OpenSUSE, CentOS 7, and RHEL 7, and is virtually non-existent in others.
• All distributions with modern kernels have some support for RELRO, with Ubuntu 18.04 leading, followed by Debian.

As mentioned, the metrics in this table are averages across all versions of the binary file. The numbers will differ if we only consider the latest versions (for example, see. progress of Debian with the implementation of PIE). Moreover, most distributions typically check the protection status of only a few functions in the binary code when calculating statistics, while our analysis indicates the true percentage of hardened functions. Thus, if a binary protects 5 out of 50 functions, we will assign it a score of 0.1, corresponding to 10% of hardened functions.

Tabel 4. Kaitse omadused käivitatavate failide jaoks, nagu on näidatud joonisel 3 (vastavate funktsioonide rakendamine protsentides kõigist käivitatavatest failidest)

Tabel 5. Kaitse omadused teekide jaoks, nagu on näidatud joonisel 3 (vastavate funktsioonide rakendamine protsentides kõigist teekidest)

Nii et edusammud on olemas? Kindlasti on: see on selgelt nähtav statistikas erinevate distributsioonide kohta (näiteks Debian), samuti eelnevalt esitatud tabelites. Näitena on joonisel 6 näidatud kaitsemehhanismide rakendamine kolmes järjestikuses Ubuntu LTS 5 distributsioonis (oleme jätnud välja virna kokkupõrke kaitse statistika). Täheldame, et versioonist versioonini toetab järjest rohkem faile virna kanarööpe, samuti tarnitakse üha rohkem binaarfailide koos täieõigusliku RELRO kaitsega.

Joon. 6

Kahjuks ei oma mitmed käivitatavad failid erinevates distributsioonides endiselt ühtegi eespool nimetatud kaitset. Näiteks vaadates Ubuntu 18.04, on silmapaistvad binaarid ngetty (getty aseaine), samuti mksh ja lksh koor, picolisp tõlkija, paketid nvidia-cuda-toolkit (populaarne pakett GPU-kiirendusega rakenduste jaoks, nagu masinõppe raamistikud) ja klibc-utils. Samuti, binaar mandos-client (haldusvahend, mis võimaldab automaatselt taaskäivitada masinad, millel on krüpteeritud failisüsteemid), samuti rsh-redone-client (rsh ja rlogin uuesti rakendamine) tarnitakse ilma NX-kaitsela, kuigi neil on SUID õigused :(. Lisaks pole mitmetes suid-binaarides baaskaitse, nagu virnastamise kanarinnad (nt Xorg.wrap binaarfail pakett Xorg-ist).

Kokkuvõte ja lõppsõnad

Selles artiklis toome välja mitmed kaasaegsete Linuxi distributiivide turvafunktsioonid. Analüüs näitas, et viimases Ubuntu LTS (18.04) distributiivis on keskmiselt kõige tugevam OS ja rakenduste taseme kaitse võrreldes suhteliselt uute kernonitega, nagu Ubuntu 14.04, 12.04 ja Debian 9. Siiski pakuvad meie analüüsis käsitletud distributiivid CentOS, RHEL ja OpenSUSE vaikimisi tihedama pakettide komplekti ning viimasetes versioonides (CentOS ja RHEL) on suurem protsent stack collision'i kaitse rakendamisest võrreldes Debian-põhiste konkurentidega (Debian ja Ubuntu). CentOSi ja RedHati versioone võrreldes täheldame suuri edusamme stack canary ja RELRO rakendamises versioonilt 6 versioonile 7, kuid keskmiselt on CentOSis rohkem funktsioone kui RHELis. Üldiselt peaksid kõik distributiivid pöörama erilist tähelepanu PIE kaitsele, mis, välja arvatud Debian 9 ja Ubuntu 18.04, on meie andmestikus rakendatud vähem kui 10% binaarfailidest.

Lõpuks tasub märkida: kuigi tegime uuringu käsitsi, on olemas palju turvavalve tööriistu (nt Lynis, Tiger, Hubble), mis nad teevad analüüsi ja aitavad vältida ebaohutuid konfigureerimisi. Kahjuks ei garanteeri isegi tugev kaitse mõistlikes seadistustes eksploitide puudumist. Seetõttu usume kindlalt, et on hädavajalik tagada usaldusväärne järelevalve ja rünnakute ennetamine reaalajas, keskendudes ekspluateerimise mudelitele ja nende ennetamisele.

Allikas: habr.com