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
