TL;DR. Në këtë artikull, ne do të shqyrtojmë skemat e mbrojtjes (hardening schemes) që funksionojnë nga kutia në pesë distribucione të njohura të Linux. Për secilin, ne morëm konfigurimin e default të bërthamës, ngarkuam të gjitha paketat dhe analizuam skemat e mbrojtjes në skedarët binarë të integruar. Distribucionet që shqyrtohen përfshijnë OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 dhe 7, si dhe Ubuntu 14.04, 12.04 dhe 18.04 LTS.
Të dhënat konfirmojnë se madje edhe skemat baze, të tilla si canary-stacks dhe kod i pavarur nga pozita, nuk përdoren ende nga të gjithë. Situata është edhe më e keqe për kompajlerët, kur bëhet fjalë për mbrojtjen nga dobësitë si përplasja e stack-ut (stack clash), të cilat morën vëmendje në janar pas publikimit . Por nuk është gjithçka aq pa shpresë. Një pjesë e konsiderueshme e binarëve implementojnë metoda të bazave mbrojtëse, dhe numri i tyre po rritet nga versioni në version.
Kontrolli tregoi se numri më i madh i metodave mbrojtëse është implementuar në Ubuntu 18.04 në nivelin e OS dhe aplikacioneve, pastaj ndjek Debian 9. Nga ana tjetër, OpenSUSE 12.4, CentOS 7 dhe RHEL 7 gjithashtu kanë implementuar skemat bazë mbrojtëse, ndërsa mbrojtja nga përplasja e stack-ut aplikohet më gjerësisht me një set më të dendur paketash si defolt.
Hyrje
Të sigurosh cilësi të lartë të softuerit është e vështirë. Pavarësisht numrit të madh të veglave të avancuara për analizën statike të kodit dhe analizën dinamike gjatë ekzekutimit, si dhe përparimeve të konsiderueshme në zhvillimin e kompajlerëve dhe gjuhëve programimi, softueri modern ende vuajti nga dobësitë që vazhdimisht shfrytëzohen nga aktorët keqdashës. Situata është edhe më e keqe në ekosistemet që përfshijnë kod të vjetëruar. Në këto raste, ne jo vetëm që ballafaqohemi me problemin e përhershëm të gjetjes së gabimeve të mundshme të shfrytëzueshme, por gjithashtu jemi të kufizuar nga kornizat rigoroze të pastrimit të prapambetjes, të cilat shpesh kërkojnë të ruajnë kodin e kufizuar, dhe sa më keq, të dobët apo me gabime.
Këtu hyjnë në lojë metodat e mbrojtjes ose forcimit të programeve (hardening). Disa lloje gabimesh nuk jemi në gjendje t'i parandalojmë, por mund të bëjmë jetën e aktorëve keqdashës më të vështirë dhe të zgjidhim pjesërisht problemin duke parandaluar ose penguar shfrytëzimin këtyre gabimeve. Kjo mbrojtje përdoret në të gjitha sistemet operative moderne, megjithatë metodat ndryshojnë shumë në kompleksitet, efektivitet dhe performancë: nga kanaret e stack-ut (stack canaries) dhe deri në mbrojtje të plotë dhe . Në këtë artikull do të shqyrtojmë metodat e mbrojtjes që aplikohen në distribucionet më të njohura të Linux në konfigurimin e parazgjedhur, si dhe do të studiojmë tiparet e binarëve që shpërndahen përmes sistemeve të menaxhimit të paketave të çdo distribucioni.
CVE dhe siguria
Të gjithë ne kemi parë artikuj me tituj si "Aplikacionet më të cenueshme të vitit" ose "Sistemet operative më të cenueshme". Zakonisht, aty jepet statistika mbi numrin total të regjistrimeve për cenueshmëri të tipit , e marrë nga nga dhe burime të tjera. Më pas, këto aplikacione ose sisteme operative renditen sipas numrit të CVE. Fatkeqësisht, ndonëse CVE janë shumë të dobishme për gjurmimin e problemeve dhe informimin e ofruesve dhe përdoruesve, ato flasin pak për sigurinë reale të softuerit.
Si një shembull, le të shqyrtojmë numrin total të CVE-ve për katër vitet e fundit për bërthamën Linux dhe pesë distribucionet më popullorë në shërbim, konkretisht Ubuntu, Debian, Red Hat Enterprise Linux dhe OpenSUSE.
Fig. 1
ĂfarĂ« na thotĂ« ky graf? A do tĂ« thotĂ« mĂ« shumĂ« CVE se njĂ« distribucion Ă«shtĂ« mĂ« i cenueshĂ«m se njĂ« tjetĂ«r? Nuk ka njĂ« pĂ«rgjigje. PĂ«r shembull, nĂ« kĂ«tĂ« artikull do tĂ« shihni se Debian ka mekanizma mbrojtĂ«s mĂ« tĂ« rreptĂ« nĂ« krahasim me OpenSUSE ose RedHat Linux, dhe megjithatĂ« Debian ka mĂ« shumĂ« CVE. MegjithatĂ«, ato nuk nĂ«nkuptojnĂ« domosdoshmĂ«risht njĂ« siguri tĂ« dobĂ«suar: edhe prania e CVE nuk tregon nĂ«se njĂ« cenueshmĂ«ri Ă«shtĂ« e shfrytĂ«zueshme. Pikat e rrezikshmĂ«risĂ« ofrojnĂ« njĂ« ide se sa e mundshme Ă«shtĂ« shfrytĂ«zimi i cenueshmĂ«risĂ«, por nĂ« fund tĂ« fundit shfrytĂ«zueshmĂ«ria varet nĂ« masĂ« tĂ« madhe nga mbrojtja e pranishme nĂ« sistemet e prekur, si dhe nga burimet dhe mundĂ«sitĂ« e sulmuesve. PĂ«r mĂ« tepĂ«r, mungesa e raporteve CVE nuk thotĂ« asgjĂ« pĂ«r cenueshmĂ«rive tĂ« pa regjistruara ose tĂ« panjohura vulnĂ©rabilitetet. Dallimi nĂ« CVE mund tĂ« shpjegohet jo nga cilĂ«sia e softuerit, por nga faktorĂ« tĂ« tjerĂ«, pĂ«rfshirĂ« burimet e ndara pĂ«r testim ose madhĂ«sinĂ« e bazĂ«s sĂ« pĂ«rdoruesve. NĂ« shembullin tonĂ«, numri mĂ« i madh i CVE-sĂ« pĂ«r Debian mund tĂ« tregojĂ« thjesht se Debian ofron mĂ« shumĂ« paketa softueri.
Sigurisht, sistemi CVE ofron informacion tĂ« dobishĂ«m qĂ« lejon krijimin e mbrojtjeve pĂ«rkatĂ«se. Sa mĂ« mirĂ« tĂ« kuptojmĂ« arsyet e dĂ«shtimit tĂ« programit, aq mĂ« e lehtĂ« Ă«shtĂ« tĂ« pĂ«rcaktojmĂ« mĂ«nyrat e mundshme tĂ« shfrytĂ«zimit dhe tĂ« zhvillojmĂ« mekanizmat pĂ«rkatĂ«s. identifikimit dhe reagimit. NĂ« fig. 2 janĂ« paraqitur kategoritĂ« e vulnerabiliteteve pĂ«r tĂ« gjitha distribucionet gjatĂ« katĂ«r viteve tĂ« fundit (). ĂshtĂ« e qartĂ« qĂ« shumica e CVE-ve bien nĂ« kategoritĂ« e mĂ«poshtme: ndalim shĂ«rbimi (DoS), ekzekutimi i kodit, mbingarkesa, dĂ«mtimi i memories, rrjedhja (ekstraktimi) i informacionit dhe eskalimi i privilegjeve. MegjithĂ«se shumĂ« CVE janĂ« renditur disa herĂ« nĂ« kategori tĂ« ndryshme, nĂ« pĂ«rgjithĂ«si, tĂ« njĂ«jtat probleme mbeten nga viti nĂ« vit. NĂ« pjesĂ«n e ardhshme tĂ« artikullit do tĂ« vlerĂ«sojmĂ« pĂ«rdorimin e skemave tĂ« ndryshme tĂ« mbrojtjes pĂ«r tĂ« parandaluar shfrytĂ«zimin e kĂ«tyre vulnerabiliteteve.
Fig. 2
Detyrat
Në këtë artikull ne synojmë të përgjigjemi në pyetjet e mëposhtme:
- Sa e sigurt Ă«shtĂ« siguria e distribucioneve tĂ« ndryshme tĂ« Linux? ĂfarĂ« mekanizmash mbrojtĂ«s ekzistojnĂ« nĂ« bĂ«rthamĂ« dhe nĂ« aplikacionet e hapĂ«sirĂ«s sĂ« pĂ«rdoruesit?
- Si ka ndryshuar ndërkohë pranimi i mekanizmave të mbrojtjes për distribucionet e ndryshme?
- Cilat janë varësitë mesatare të paketa dhe bibliotekave për çdo distribucion?
- Cilat mbrojtje janë implementuar për çdo binar?
Zgjedhja e distribucioneve
Kuptohet se është e vështirë të gjenim statistika të sakta mbi instalimet e distribucioneve, pasi në shumicën e rasteve numri i shkarkimeve nuk tregon numrin e instalimeve reale. Megjithatë, opsionet Unix përbëjnë shumicën e sistemeve server (në serverat web 69.2%, sipas W3techs dhe burimeve të tjera), dhe pjesa e tyre është duke u rritur vazhdimisht. Pra, për hulumtimin tonë, ne u përqendruam në distribucionet që janë të disponueshme jashtë kutisë në platformën . Në veçanti, ne zgjodhëm sistemet operative si më poshtë:
Distribucioni/versioni
BĂ«rthama
Ndërtimi
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
Do të shqyrtojmë konfigurimin e kernelit të paracaktuar, si dhe vetitë e paketeve të aksesueshme përmes menaxherit të paketave për çdo distro nga kuti. Kështu, ne do të shqyrtojmë vetëm pakete nga pasqyrat e paracaktuara të çdo distrose, duke e injoruar paketat nga repositorët e paqëndrueshëm (p.sh., pasqyrat 'testing' në Debian) dhe paketat e jashtme (p.sh., paketat Nvidia nga pasqyrat standard). Për më tepër, ne nuk do të shqyrtojmë kompilimet e përdoruesve të kernelit apo konfigurimet me nivel të lartë mbrojtjeje.
Analiza e konfigurimit të kernelit
Ne aplikuam një skenar analize të bazuar në . Ne shqyrtojmë parametrat e mbrojtjes të paracaktuar në distro-t e përmendura dhe i krahasojmë ato me listën nga (KSPP). Për çdo parametrat e konfigurimit, tabela 2 përshkruan konfigurimin e dëshiruar: një shenjë e markuar për distro-t që përputhen me rekomandimet KSSP (shpjegimi i terminologjisë është i disponueshëm në ; në artikujt e ardhshëm do të flasim se si janë shfaqur shumë nga këto metoda mbrojtjeje dhe si të komprometoni sistemin në mungesë të tyre).
NĂ« pĂ«rgjithĂ«si, nĂ« kernelĂ«t e rinj ka konfigurime mĂ« tĂ« rrepta tĂ« paracaktuara. PĂ«r shembull, nĂ« CentOS 6.10 dhe RHEL 6.10 me kernelin 2.6.32 mungojnĂ« shumicĂ«n e funksioneve kritike tĂ« implementuara nĂ« kernelĂ«t e rinj, si , lejet e rrepta RWX, randomizimi i adresave ose mbrojtja e copy2usr. Duhet theksuar se shumĂ« nga opsionet e konfigurimit nga tabela mungojnĂ« nĂ« versionet mĂ« tĂ« vjetra tĂ« kernelit dhe nuk janĂ« tĂ« aplikueshme nĂ« praktikĂ« â nĂ« tabelĂ« kjo ende tregohet si mungesĂ« mbrojtjeje tĂ« duhur. Po ashtu, nĂ«se njĂ« parametrat e konfigurimit mungon nĂ« kĂ«tĂ« version, dhe pĂ«r siguri ky parametr duhet tĂ« çaktivizohet, kjo konsiderohet njĂ« konfigurim i arsyeshĂ«m.
Një moment tjetër kur interpretojmë rezultatet: disa konfiguracione të bërthamës që rrisin sipërfaqen e sulmit mund të përdoren gjithashtu për sigurimin. Disa shembuj përfshijnë uprobes dhe kprobes, modul të bërthamës dhe BPF/eBPF. Rekomandimi ynë është që të përdoren mekanizmat e përmendur më sipër për të siguruar mbrojtje reale, pasi ato nuk janë të thjeshta për t'u përdorur, dhe shfrytëzimi i tyre nënkupton që subjektet e këqija tashmë janë instaluar në sistem. Por nëse këto parametra aktivizohen, administratori i sistemit duhet të ndjekë aktivisht abuzimet.
Duke shqyrtuar mĂ« tej rekordet e tabelĂ«s 2, shohim se bĂ«rthamat moderne ofrojnĂ« disa mundĂ«si pĂ«r tĂ« mbrojtur nga shfrytĂ«zimi i tĂ« tillave si rrjedhja e informacionit dhe mbushja e stack-ut/heaps. MegjithatĂ«, vĂ«rejmĂ« se edhe shpĂ«rndarjet mĂ« tĂ« fundit ende nuk kanĂ« implementuar mbrojtje mĂ« tĂ« avancuar (p.sh., me patches ) ose mbrojtje moderne nga sulmet e ripĂ«rdorimit tĂ« kodit (p.sh., ). ĂfarĂ« Ă«shtĂ« edhe mĂ« e keqe, edhe kĂ«to mjete mĂ« tĂ« avancuara nuk mbrojnĂ« nga spektri i plotĂ« i sulmeve. Prandaj, Ă«shtĂ« tepĂ«r e rĂ«ndĂ«sishme pĂ«r administratorĂ«t e sistemeve tĂ« plotĂ«sojnĂ« konfigurimet e arsyeshme me zgjidhje qĂ« ofrojnĂ« zbulim dhe parandalim tĂ« shfrytĂ«zimeve gjatĂ« ekzekutimit.
Analiza e aplikacioneve
Nuk është çudi që shpërndarjet e ndryshme kanë karakteristika të ndryshme të pakove, parametrave të përpilimit, varësive të bibliotekave, etj. Dallimet ekzistojnë edhe për të ngjashme dhe pako me varësi të vogla (p.sh., coreutils në Ubuntu ose Debian). Për të vlerësuar dallimet, ne shkarkuam të gjitha paketat e disponueshme, nxorrëm përmbajtjen e tyre dhe analizuam skedarët binare dhe varësitë. Për secilën paketë ndjekëm paketat e tjera nga të cilat ajo varet, dhe për çdo binar ndjekëm varësitë e tij. Në këtë seksion do të paraqesim përmbledhjen e gjetjeve.
Shpërndarjet
Në total kemi ngarkuar 361,556 paketa për të gjitha shpërndarjet, duke nxjerrë vetëm paketa nga pasqyrat e paracaktuara. Ne injoruam paketat pa skedarë ekzekutivë ELF, si kodet burimore, fontet, etj. Pas filtrimit, mbetën 129,569 paketa, që përmbajnë gjithsej 584,457 skedarë binarë. Shpërndarja e paketave dhe skedarëve sipas shpërndarjeve është e ilustruar në figurën 3.
Fig. 3
Vërehet se sa më moderne të jetë shpërndarja, aq më shumë paketa dhe skedarë binarë ka, që është logjike. Megjithatë, paketat Ubuntu dhe Debian përfshijnë shumë më tepër skedarë binarë (si skedarë ekzekutivë, ashtu edhe module dinamike dhe biblioteka), sesa CentOS, SUSE dhe RHEL, gjë që potencialisht ndikon në sipërfaqen e sulmit të Ubuntu dhe Debian (duhet të theksohet se shifrat reflektojnë të gjithë binarët e të gjitha versioneve të paketës, që do të thotë se disa skedarë analizohet disa herë). Kjo është veçanërisht e rëndësishme duke pasur parasysh varësitë midis paketave. Në këtë mënyrë, një ndjeshmëri në një binar të një pakete mund të ndikojë në shumë pjesë të ekosistemit, ashtu si një bibliotekë e ndjeshme mund të ndikojë në të gjithë skedarët binarë që e importojnë atë. Si një pikë referimi, le të shohim shpërndarjen e numrit të varësive sipas paketave në sistemet operative të ndryshme:
Fig. 4
Gati në të gjitha shpërndarjet, 60% e paketimeve kanë të paktën 10 varësi. Përveç kësaj, disa pakete kanë shumë më tepër varësi (më shumë se 100). E njëjta gjë vlen dhe për varësitë e kundërta të paketave: siç pritej, disa paketa përdoren nga shumë paketa të tjera në shpërndarje, prandaj ndjeshmëritë në këto disa të përzgjedhura kanë një rrezik të lartë. Si një shembull në tabelën e ardhshme janë listuar 20 paketa me numrin më të madh të varësive të kundërta në SLES, Centos 7, Debian 9 dhe Ubuntu 18.04 (në çdo qelizë është e shënuar paketa dhe numri i varësive të kundërta).
Tabela 3
Fakti interesant. Edhe pse të gjitha sistemet operative të analizuar janë ndërtuar për arkitekturën x86_64, dhe për shumicën e paketimeve arkitektura është e përcaktuar si x86_64 dhe x86, paketat shpesh përmbajnë skedarë binarë për arkitektura të tjera, siç ilustrohet në figurën 5.
Fig. 5
Në seksionin e ardhshëm do të thellohemi në karakteristikat e binarëve të analizuar.
Statistika për mbrojtjen e skedarëve binarë
Si minimum absolut, është e nevojshme të studioni një grup bazik variantesh mbrojtjeje për skedarët binarë ekzistues. Disa distribucione Linux vijnë me skripte që kryejnë këto verifica. Për shembull, në Debian/Ubuntu ka një skript të tillë. Ja një shembull i funksionimit të tij:
$ hardening-check $(which docker)
/usr/bin/docker:
Pozita Pavarur Ekzekutiv: po
Staku i mbrojtur: po
Funksionet Fortify Source: jo, vetëm funksione të pambrojtura të gjetura!
Rishikimet e lexueshme: po
Ndryshimi i menjëhershëm: poSkripti kontrollon pesë :
- Pozita Pavarur Ekzekutiv (PIE): tregon nëse mund të zhvendoset në memorie seksioni tekstor i programit për të arritur rastësi, nëse ASLR është aktivizuar në kernel.
- Staku i Mbrojtur: a janë aktivizuar kanaret e stack-ut për të mbrojtur nga sulmet në përplasje staku.
- Fortify Source: a zëvendësohen funksionet e pasigurta (për shembull, strcpy) me ekuivalentët e tyre më të sigurt, dhe thirrjet e verifikuara në kohë ekzekutimi - me ekuivalentët e tyre të pa verifikuar (për shembull, memcpy në vend të __memcpy_chk).
- Rishikimet e lexueshme (RELRO): a janë etiketuar regjistrimet e tabelës së zhvendosjes si "të lexueshme vetëm", nëse ato janë aktivizuar para fillimit të ekzekutimit.
- Ndarja e menjëhershme (binding i menjëhershëm): a lejon linkuesi i mjedisit të ekzekutimit që të zgjidhë të gjitha zhvendosjet para fillimit të ekzekutimit të programit (kjo është ekuivalente me RELRO të plotë).
A janë mjaft të mësipërmet mekanizmat e mbrojtjes? Fatkeqësisht, jo. Janë të njohura mënyra për të anashkaluar të gjitha mbrojtjet e mëparshme, por sa më e fortë të jetë mbrojtja, aq më i lartë është nivelin për sulmuesin. Për shembull, janë më të vështira për t'u aplikuar nëse vepron PIE dhe ndarja e menjëhershme. Ngjashëm, ASLR e plotë kërkon punë të shtuar për të krijuar një exploiter funksional. Sidoqoftë, sulmues të sofistikuar tashmë janë të gatshëm për t'u përballur me këto mbrojtje: mungesa e tyre principalisht do të përshpejtojë thyerjen. Prandaj, është jashtëzakonisht e rëndësishme që këto masa të merren parasysh si një minimum të nevojshëm minimum.
Ne deshëm të studionim për sa shumë skedarë binarë në distribucionet e shqyrtuara janë mbrojtur me këto, si dhe me tre metoda të tjera:
- Bit i paekzekutueshëm () parandalon ekzekutimin në çdo rajon që nuk duhet të jetë ekzekutiv, për shembull në heap-in e stack-ut etj.
- tregon rruge ekzekutimi, e cila përdoret nga ngarkuesi dinamik për të gjetur bibliotekat përkatëse. E para është e detyrueshme për çdo sistem modern: mungesa e saj lejon hakerët të shkruajnë informacionin në memorie dhe ta ekzekutojnë atë siç është. Për të dytin, konfigurime të gabuara të rrugëve të ekzekutimit ndihmojnë në futjen e kodit të paqartë, që mund të çojë në një sërë problemesh (p.sh., , si dhe ).
- Mbrojtja nga përplasje të stack siguron mbrojtje nga sulmet që shkaktojnë që stack të mbivendoset në zona të tjera të memories (p.sh., në heap). Duke marrë parasysh eksploitimet e fundit që abuzojnë , ne e konsideruam të arsyeshme të përfshijmë këtë mekanizëm në të dhënat tona.
Pra, pa më tej ceremonira, le të kalojmë në numra. Tabelat 4 dhe 5 përmbajnë një përmbledhje të analizës së skedarëve ekzekutues dhe bibliotekave të shpërndarjeve të ndryshme, përkatësisht.
- Siç mund të vërehet, mbrojtja NX është e implementuar në të gjithë, përveç disa përjashtimeve. Në veçanti, duket se përdorimi i saj është disi më i ulët në shpërndarjet Ubuntu dhe Debian në krahasim me CentOS, RHEL dhe OpenSUSE.
- Canary stack mungon në shumë vende, veçanërisht në shpërndarjet me bërthamë të vjeter. Disa përparim është vërejtur në shpërndarjet më të fundit CentOS, RHEL, Debian dhe Ubuntu.
- Përveç Debian dhe Ubuntu 18.04, në shumicën e shpërndarjeve ka mbështetje të dobët për PIE.
- Mbrojtja nga përplasje të stack është implementuar dobët në OpenSUSE, CentOS 7 dhe RHEL 7 dhe praktikisht mungon në të tjerat.
- Të gjitha shpërndarjet me bërthama moderne kanë një mbështetje të caktuar për RELRO, me udhëheqje nga Ubuntu 18.04, ndërsa vendi i dytë mbahet nga Debian.
Siç u përmend, metrikat në këtë tabelë janë mesatare për të gjitha versionet e skedarëve binarë. Nëse shikoni vetëm versionet më të fundit të skedarëve, atëherë numrat do të jenë ndryshe (p.sh., shih ). Për më tepër, shumica e shpërndarjeve zakonisht, gjatë llogaritjes së statistikave, kontrollojnë mbrojtjen e vetëm disa funksioneve në kodin binar, ndërsa në analizën tonë është e specifikuar përqindja e vërtetë e funksioneve të forcuara. Prandaj, nëse në një binar janë të mbrojtura 5 nga 50 funksione, ne do t'i japim asaj një vlerësim 0,1, që korrespondon me 10% të funksioneve të forcuara.
Tabela 4. Karakteristikat e mbrojtjes për skedarët ekzekutues, të ilustruar në figurën 3 (implementimi i funksioneve përkatëse në përqindje të totalit të skedarëve ekzekutues)
Tabela 5. Karakteristikat e mbrojtjes për bibliotekat e paraqitura në figurën 3 (implementimi i funksioneve përkatëse në përqindje të numrit total të biblioteka)
A ka progres? Definitivisht ka: kjo duket nga statistikat për distribuime të veçanta (për shembull, ), si dhe nga tabelat e paraqitura më sipër. Si një shembull, në figurën 6 tregohet implementimi i mekanizmave të mbrojtjes në tri distribuime të njëpasnjëshme të Ubuntu LTS 5 (ne e kemi lënë jashtë statistikën e mbrojtjes nga përplasje të stack-ut). Vërejmë se nga versioni në version gjithnjë e më shumë skedarë mbështesin kanatat e stack-ut dhe gjithashtu gjithnjë e më shumë skedarë binarë shpërndahen me mbrojtje të plotë RELRO.
Figura 6
Fatkeqësisht, një numër i skedarëve ekzekutivë në distribuime të ndryshme ende nuk ka asnjë nga mbrojtjet e lartpërmendura. Për shembull, duke shikuar në Ubuntu 18.04, mund të vëreni binarin ngetty (zëvendësim për getty), si dhe shell-in mksh dhe lksh, interpretuest picolisp, paketat nvidia-cuda-toolkit (një paketë e njohur për aplikacione me përshpejtim GPU, siç janë kornizat e mësimit të makinerive) dhe klibc-utils. Në mënyrë të ngjashme, binari mandos-client (një mjet administrativ që lejon ri-ngarkimin automatik të makinave me sisteme skedarësh të enkriptuar), si dhe rsh-redone-client (rishtazimi i rsh dhe rlogin) shpërndahen pa mbrojtje NX, megjithëse ata kanë të drejta SUID :(. Për më tepër, në disa binarë SUID nuk ka mbrojtje bazë, siç janë kanatat e stack-ut (për shembull, skedari binar Xorg.wrap nga paketa Xorg).
Përmbledhje dhe vërejtje përfundimtare
Në këtë artikull, ne theksojmë disa nga karakteristikat e sigurisë së shpërndarjeve moderne të Linux. Analiza ka treguar se distribucioni më i fundit LTS i Ubuntu (18.04) ofron mbrojtjen më të fortë në nivelin e sistemit operativ dhe aplikacioneve ndërmjet shpërndarjeve me bërthama relativisht të reja, si Ubuntu 14.04, 12.04 dhe Debian 9. Megjithatë, shpërndarjet e shqyrtuara CentOS, RHEL dhe OpenSUSE në setin tonë të të dhënave, si rregull, ofrojnë një paketë më të dendur, dhe në versionet e fundit (CentOS dhe RHEL) kanë një përqindje më të lartë të zbatimit të mbrojtjes nga përplasje të stack-ut, krahasuar me competitorët bazuar në Debian (Debian dhe Ubuntu). Duke krahasuar versionet CentOS dhe RedHat, ne vërejmë përparime të mëdha në zbatimin e kanarinave të stack-ut dhe RELRO nga versionet 6 në 7, por mesatarisht në CentOS janë implementuar më shumë funksionalitete sesa në RHEL. Në përgjithësi, të gjitha shpërndarjet duhet të kushtojnë vëmendje të posaçme mbrojtjes PIE, e cila, përveç Debian 9 dhe Ubuntu 18.04, është zbatuar në më pak se 10% të skedarëve binarë nga seti ynë i të dhënave.
Në fund, duhet theksuar: ndonëse ne kemi kryer hulumtimin manualisht, ekzistojnë shumë mjete sigurie (p.sh., , , ), të cilat kryejnë analiza dhe ndihmojnë në shmangien e konfigurimeve të pasigurta. Fatkeqësisht, edhe mbrojtja më e fortë në konfigurime të arsyeshme nuk garanton mungesën e eksploitëve. Kjo është arsyeja pse ne besojmë me forcë se është thelbësore të sigurohet , duke u përqendruar në modelet e eksploatimit dhe duke i parandaluar ato.
Burimi: habr.com
