TL;DR. Në këtë artikull ne shqyrtojmë skemat mbrojtëse (hardening schemes) që funksionojnë nga kutia në pesë distribucione të njohura Linux. Për secilin kemi marrë konfigurimin e bërthames si ndihmë, kemi shkarkuar të gjitha paketat dhe kemi analizuar skemat e mbrojtjes në skedarët binarë të përfshirë. Diskutohen distribucionet 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 bazë, si kanarinat në skedë dhe kodi i pavarur nga pozita, ende nuk përdoren nga të gjithë. Situata është edhe më e keqe me kompjilatorët kur bëhet fjalë për mbrojtjen nga dobësitë siç është përplasjeja e skedave (stack clash), e cila ka marrë vëmendje në janar pas publikimit . Por nuk është gjithçka kaq dëshpëruese. Në një pjesë të madhe të binarëve janë zbatuar metoda të bazuara mbrojtëse, dhe numri i tyre po rritet nga versioni në version.
Kontrolli tregoi se numri më i madh i metodave të mbrojtjes është realizuar në Ubuntu 18.04 në nivelin e OS dhe aplikacioneve, të ndjekur nga Debian 9. Nga ana tjetër, në OpenSUSE 12.4, CentOS 7 dhe RHEL 7 gjithashtu janë realizuar skemat themelore të mbrojtjes, dhe mbrojtja nga përplasje të stack-ut aplikohet edhe më gjerësisht në një grup shumë më të dendur paketash siç është në mënyrë të parazgjedhur.
Hyrje
ĂshtĂ« e vĂ«shtirĂ« tĂ« sigurohet njĂ« cilĂ«si e lartĂ« e softuerit. MegjithĂ«se ekziston njĂ« numĂ«r i madh mjetesh tĂ« avancuara pĂ«r analizĂ«n statike tĂ« kodit dhe analizĂ«n dinamike gjatĂ« ekzekutimit, si dhe pĂ«rparime tĂ« konsiderueshme nĂ« zhvillimin e kompajlerĂ«ve dhe gjuhĂ«ve tĂ« programimit, softueri modern ende vuajti nga dobĂ«si qĂ« vazhdojnĂ« tĂ« shfrytĂ«zohen nga sulmuesit. Situata Ă«shtĂ« akoma mĂ« e keqe nĂ« ekosistemet qĂ« pĂ«rfshijnĂ« kod tĂ« vjetruar. NĂ« kĂ«to raste, ne jo vetĂ«m qĂ« pĂ«rballemi me problemin e pĂ«rhershĂ«m tĂ« identifikimit tĂ« gabimeve qĂ« mund tĂ« shfrytĂ«zohen, por jemi tĂ« kufizuar nga korniza rigoroze tĂ« pĂ«rputhshmĂ«risĂ« prapa, tĂ« cilat shpesh kĂ«rkojnĂ« qĂ« tĂ« ruajmĂ« kodin e kufizuar, dhe akoma mĂ« keq, tĂ« dobĂ«t ose me probleme.
Këtu hyjnë në lojë metodat e mbrojtjes ose forcuese (hardening). Disa lloje gabimesh ne nuk mund t'i parandalojmë, por mund t'i bëjmë jetën një sulmuesi më të vështirë dhe të zgjidhim pjesërisht problemin duke parandaluar ose penguar këto gabime. eksploatimi Kjo mbrojtje përdoret në të gjitha sistemet operuese moderne, por metodat ndryshojnë shumë në kompleksitet, eficiencë dhe performancë: nga kanaret e stackut (stack canaries) dhe deri te mbrojtjet e plota. dhe . Në këtë artikull do të shqyrtojmë se cilat metoda mbrojtjeje përdoren në shpërndarjet më të njohura të Linux në konfigurimin e tyre siç është parazgjedhur, si dhe do të studiojmë vetitë e binarëve që shpërndahen përmes sistemeve të menaxhimit të paketave për çdo shpërndarje.
CVE dhe siguria
Të gjithë ne kemi parë artikuj me tituj të tillë si "Aplikacionet më të prekura të vitit" ose "Sistemet operuese më të prekura." Zakonisht, atje paraqiten statistika për numrin e përgjithshëm të regjistrimeve të dobësive, të tilla si , e marrë nga nga dhe burimeve të tjera. Më vonë, këto aplikacione ose OS renditen sipas numrit të CVE. Fatkeqësisht, megjithëse CVE janë shumë të dobishme për ndjekjen e problemeve dhe informimin e ofruesve dhe përdoruesve, ato thonë pak për sigurinë reale të software-it.
Për shembull, le të shikojmë numrin e përgjithshëm të CVE për katër vitet e fundit për bërthamën Linux dhe pesë shpërndarjet më të njohura të serverëve, konkretisht Ubuntu, Debian, Red Hat Enterprise Linux dhe OpenSUSE.
Fig. 1
ĂfarĂ« na thotĂ« ky grafik? A do tĂ« thotĂ« numri mĂ« i madh i CVE se njĂ« shpĂ«rndarje Ă«shtĂ« mĂ« e ekspozuar se tjetra? PĂ«rgjigjja Ă«shtĂ« jo. PĂ«r shembull, nĂ« kĂ«tĂ« artikull do tĂ« shihni se Debian ka mekanizma mbrojtjeje mĂ« tĂ« fortĂ« nĂ« krahasim me, pĂ«r tĂ« thĂ«nĂ«, OpenSUSE ose RedHat Linux, dhe megjithatĂ« Debian ka mĂ« shumĂ« CVE. MegjithatĂ«, ato nuk do tĂ« thonĂ« domosdoshmĂ«risht njĂ« siguri mĂ« tĂ« dobĂ«t: edhe pranimi i CVE nuk thotĂ« nĂ«se njĂ« vlerĂ«sim Ă«shtĂ« i shfrytĂ«zueshĂ«m. PikĂ«t e rĂ«ndĂ«sisĂ« japin njĂ« pasqyrĂ« se sa e mundshme pĂ«rdorimi i dobĂ«sive, por nĂ« fund tĂ« fundit shfrytshmĂ«ria nĂ« masĂ« tĂ« madhe varet nga mbrojtja e pranishme nĂ« sistemet e prekura, si dhe nga burimet dhe kapacitetet e sulmuesve. PĂ«r mĂ« tepĂ«r, mungesa e raporteve CVE nuk tregon asgjĂ« pĂ«r tĂ« tjera tĂ« pa regjistruara ose tĂ« panjohura dobĂ«si. Diferenca nĂ« CVE mund tĂ« shpjegohet jo nga cilĂ«sia e softuerit, por nga faktorĂ« tĂ« tjerĂ«, duke pĂ«rfshirĂ« burimet e ndara pĂ«r testim, ose madhĂ«sinĂ« e bazĂ«s sĂ« pĂ«rdoruesve. NĂ« rastin tonĂ«, njĂ« numĂ«r mĂ« i madh CVE nĂ« Debian mund tĂ« tregojĂ« thjesht se Debian ofron mĂ« shumĂ« paketa softueri.
Natyrisht, sistemi CVE ofron informacion tĂ« dobishĂ«m qĂ« lejon krijimin e mbrojtjeve pĂ«rkatĂ«se. Sa mĂ« mirĂ« ta kuptojmĂ« shkakun e dĂ«shtimit tĂ« programit, aq mĂ« e lehtĂ« Ă«shtĂ« tĂ« pĂ«rcaktojmĂ« mundĂ«sitĂ« e shfrytĂ«zimit dhe tĂ« zhvillojmĂ« mekanizma pĂ«rkatĂ«s pĂ«r zbulim dhe reagim. NĂ« fig. 2 janĂ« treguar kategoritĂ« e dobĂ«sive pĂ«r tĂ« gjitha shpĂ«rndarjet gjatĂ« katĂ«r viteve tĂ« fundit (). ĂshtĂ« menjĂ«herĂ« e dukshme se shumica e CVE-tĂ« bien nĂ« katĂ«r kategori kryesore: shĂ«rbimi i refuzuar (DoS), ekzekutimi i kodit, mbushja e kufijve, dĂ«mtimi i memories, shkalla e informacionit dhe escalimi i privilegjeve. MegjithĂ«se shumĂ« CVE janĂ« regjistruar disa herĂ« nĂ« kategori tĂ« ndryshme, nĂ« pĂ«rgjithĂ«si tĂ« njĂ«jtat probleme pĂ«rsĂ«riten nga viti nĂ« vit. NĂ« pjesĂ«n tjetĂ«r tĂ« artikullit do tĂ« vlerĂ«sojmĂ« pĂ«rdorimin e skemave tĂ« ndryshme tĂ« mbrojtjes pĂ«r tĂ« parandaluar shfrytĂ«zimin e dobĂ«sive tĂ« pĂ«rmendura.
Fig. 2
Detyrat
Në këtë artikull, ne synojmë të përgjigjemi në pyetje të mëposhtme:
- Cila është siguria e distribucioneve të ndryshme Linux? Cilët mekanizma mbrojtjeje ekzistojnë në bërthamë dhe aplikacione të hapësirës së përdoruesit?
- Si ka ndryshuar me kalimin e kohës pranuarja e mekanizmave të mbrojtjes për distribucione të ndryshme?
- Cilat janë varësitë mesatare të paketave dhe biblioteka për secilin distribucion?
- Cilat mbrojtje janë realizuar për çdo binar?
Zgjedhja e distribuzioneve
ĂshtĂ« e vĂ«shtirĂ« tĂ« gjesh statistika tĂ« saktĂ« pĂ«r 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 serverike (nĂ« serverĂ«t web 69,2%, sipas W3techs dhe burimeve tĂ« tjera), dhe pjesa e tyre po rritet vazhdimisht. Prandaj, pĂ«r hulumtimin tonĂ«, u fokusuam nĂ« distribucionet e disponueshme nga kutia nĂ« platformĂ«n . NĂ« veçanti, ne zgjodhĂ«m sistemet eksploruese:
Distribucioni/versioni
Nuk është
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 bĂ«rthamĂ«s sĂ« parazgjedhur, si dhe vetitĂ« e pakove qĂ« janĂ« tĂ« disponueshme pĂ«rmes menaxherit tĂ« paketave tĂ« çdo distribuimi nga kutia. KĂ«shtu, ne shqyrtojmĂ« vetĂ«m pakot nga pasqyrat e parazgjedhura tĂ« çdo distribuimi, duke injoruar pakot nga depozitat e pasiguruara (p.sh., pasqyrat âtestingâ nĂ« Debian) dhe pakot e jashtme (p.sh., paketat Nvidia nga pasqyrat standarde). PĂ«r mĂ« tepĂ«r, ne nuk shqyrtojmĂ« kompilimet e personalizuara tĂ« bĂ«rthamĂ«s ose konfigurimet me siguri tĂ« pĂ«rmirĂ«suar.
Analiza e konfigurimit të bërthamës
Ne aplikuam një skript analize të bazuar në . Ne shqyrtojmë parametrat e mbrojtjes nga kutia tek distribuimet e përmendura dhe i krahasojmë ato me listën nga (KSPP). Për çdo parameter konfigurimi, tabela 2 përshkruan konfigurimin e dëshiruar: një shenjë është për distribuimet që përputhen me rekomandimet e KSSP (shpjegimi i termaeve shikohet ; në artikujt e ardhshëm do të flasim për mënyrat si kanë lindur shumë prej këtyre metodave të mbrojtjes dhe si të thyen sistemin në mungesë të tyre).
NĂ« pĂ«rgjithĂ«si, bĂ«rthamat e reja kanĂ« konfigurime mĂ« strikte nga fabrika. PĂ«r shembull, nĂ« CentOS 6.10 dhe RHEL 6.10 me bĂ«rthamĂ«n 2.6.32 nuk ka shumicĂ«n e funksioneve kritike tĂ« implementuara nĂ« bĂ«rthamat e reja, si , lejet strikte RWX, randomizimi i adresave ose mbrojtja copy2usr. Vlen tĂ« theksohet se shumĂ« nga variantet e konfigurimit nĂ« tabelĂ« mungojnĂ« nĂ« versionet mĂ« tĂ« vjetra tĂ« bĂ«rthamĂ«s dhe nuk janĂ« tĂ« aplikueshme nĂ« realitet â nĂ« tabelĂ« kjo ende shĂ«nohet si mungesĂ« mbrojtjeje tĂ« duhur. Po ashtu, nĂ«se njĂ« parametĂ«r konfigurimi mungon nĂ« kĂ«tĂ« version dhe pĂ«r siguri ky parametr duhet tĂ« çaktivizohet, kjo konsiderohet si njĂ« konfigurim i arsyeshĂ«m.
Një tjetër moment në interpretimin e rezultateve: disa konfigurime të bërthamës që rrisin sipërfaqen e sulmit mund të përdoren gjithashtu për siguri. Shembuj të tillë përfshijnë uprobes dhe kprobes, module bërthame dhe BPF/eBPF. Rekomandimi ynë është që të përdoren mekanizmat e mësipërm për të siguruar mbrojtje reale, pasi ato nuk janë triviale për t'u përdorur dhe shfrytëzimi i tyre nënkupton se subjektet e dëmshme tashmë janë të vendosura në sistem. Por nëse këto opcione janë të aktivizuara, administratori i sistemit duhet të mbajë aktivisht nën kontroll abuzimet.
Duke studiuar mĂ« tej shĂ«nimet e tabelĂ«s 2, ne shohim se bĂ«rthamat moderne ofrojnĂ« disa mundĂ«si pĂ«r mbrojtjen nga shfrytĂ«zimi i dobĂ«sive tĂ« tilla si rrjedhja e informacionit dhe mbushja e stakĂ«s/pllakĂ«s. MegjithatĂ«, vĂ«rejmĂ« se edhe distribucionet mĂ« tĂ« fundit tĂ« njohura ende nuk e kanĂ« implementuar mbrojtjen mĂ« tĂ« avancuar (p.sh., me patch-e ) ose mbrojtjen moderne nga sulmet e ripĂ«rdorimit tĂ« kodit (p.sh., ). ĂfarĂ« Ă«shtĂ« mĂ« keq, edhe kĂ«to mjete mĂ« tĂ« avancuara mbrojtjeje nuk ofrojnĂ« mbrojtje nga spektri i plotĂ« i sulmeve. Prandaj, Ă«shtĂ« tejet e rĂ«ndĂ«sishme pĂ«r administratorĂ«t e sistemeve tĂ« plotĂ«sojnĂ« konfigurimet e arsyeshme me zgjidhje qĂ« ofrojnĂ« zbćç° dhe parandalimin e shfrytĂ«zimeve gjatĂ« ekzekutimit.
Analiza e aplikacioneve
Nuk është çudi që shpërndarjet e ndryshme kanë karakteristika të ndryshme paketash, parametrave të kompilimit, varësive të bibliotekave etj. Dallimet ekzistojnë madje edhe për dhe paketat me pak varësi (p.sh., coreutils në Ubuntu ose Debian). Për të vlerësuar dallimet, ne ngarkuam të gjitha paketat në dispozicion, nxorrëm përmbajtjen e tyre dhe analizuam skedarët binarë dhe varësitë. Për çdo paketë, ne ndoqëm paketat e tjera nga të cilat ajo varet, dhe për çdo skedar binar ndoqëm varësitë e tij. Në këtë seksion do të shpalosim përmbledhjen e konkluzioneve.
Shpërndarjet
Në total, kemi shkarkuar 361 556 paketa për të gjithë shpërndarjet, duke nxjerrë vetëm paketat nga mirror-ët e paracaktuar. Ne injoruam paketat pa skedarë ekzekutivë ELF, të tilla si kodet burimorë, fontet etj. Pas filtrimit, mbetën 129 569 paketa, që përmbanin në total 584 457 skedarë binarë. Distribucioni i paketave dhe skedarëve sipas shpërndarjeve është treguar në Fig. 3.
Fig. 3
Vërehet se sa më moderne të jetë distribucioni, aq më shumë paketa dhe skedarë binarë ka në të, që është logjik. Ndërkohë, paketat Ubuntu dhe Debian përfshijnë shumë më tepër skedarë binarë (si skedarë ekzekutivë ashtu edhe module dhe biblioteka dinamike) se sa CentOS, SUSE dhe RHEL, gjë që potencialisht ndikon në sipërfaqen e sulmit të Ubuntu dhe Debian (duhet të vërehet se numrat pasqyrojnë të gjitha binarët e të gjitha versioneve të paketës, domethënë disa skedarë analizohen disa herë). Kjo është veçanërisht e rëndësishme duke marrë parasysh varësitë mes paketimeve. Pra, një dobësi në një skedar binar të një pakete mund të ndikojë në shumë pjesë të ekosistemit, ndryshe nga një bibliotekë e cenueshme që mund të ndikojë në të gjithë skedarët binarë që e importojnë atë. Si pikë reference, le të shohim shpërndarjen e numrit të varësive sipas paketimeve në sisteme të ndryshme operative:
Fig. 4
Në pothuajse të gjitha shpërndarjet, 60% e paketimeve kanë të paktën 10 varësi. Për më tepër, disa paketa kanë një numër ndihmësish shumë më të madh (më shumë se 100). E njëjta gjë vlen edhe për varësitë e bëra në paketa: siç pritej, disa paketa përdoren nga shumë paketa të tjera në shpërndarje, kështu që dobësitë në këto disa të zgjedhur kanë rrezik të lartë. Si një shembull, në tabelën e mëposhtme listohen 20 paketa me numrin maksimal të varësive të kthyeshme në SLES, Centos 7, Debian 9 dhe Ubuntu 18.04 (në çdo qelizë është përfshirë emri i pakos dhe numri i varësive të kthyeshme).
Tabela 3
Fakti interesant. Megjithëse të gjitha sistemet operuese që po analizohen janë ndërtuar për arkitekturën x86_64, dhe shumica e paketimeve kanë arkitekturë të përcaktuar si x86_64 dhe x86, paketat shpesh përmbajnë skedarë binarë për arkitektura të tjera, siç tregohet në fig. 5.
Fig. 5
Në seksionin e ardhshëm, do të thellohemi në karakteristikat e analizuar të binarëve.
Statistika e mbrojtjes së skedarëve binarë
Si një minimum absolut, është e nevojshme të studiohen një grup bazik opsionesh mbrojtjeje për skedarët binarë që ekzistojnë. Disa distribucione Linux vijnë me skripta që kryejnë këto kontrollime. Për shembull, në Debian/Ubuntu ekziston një tjetër skript. Ky është një shembull i funksionimit të tij:
$ hardening-check $(which docker)
/usr/bin/docker:
Ekzekutiv i Pavarur nga Pozita: po
Staku i mbrojtur: po
Funksionet e Burimeve të Forsuara: jo, vetëm funksione të pambrojtura u gjetën!
Rëndësia e shkëputur: po
Lidhje e menjëhershme: poSkripti kontrollon pesë :
- Ekzekutiv i Pavarur nga Pozita (PIE): tregon nëse mund të zhvendoset në kujtesë seksioni i tekstit të programit për të arritur rastësinë, nëse ASLR është e aktivizuar në bërthamë.
- Staku i Mbrojtur: nëse kanaret e stack janë aktivizuar për mbrojtje nga sulmet e përplasjeve të stack.
- Burimi i Forcuar: nëse funksionet e pasigurta (p.sh., strcpy) zëvendësohen me homologët e tyre më të sigurt, dhe thirrjet e kontrolluara gjatë ekzekutimit me ato të pambrojtura (p.sh., memcpy në vend të __memcpy_chk).
- Rindarjet e lexueshme (RELRO): nëse shkurtimet e tabelës së rindarjes janë shënuar si "të lexueshme vetëm", nëse ato u aktivizuan para fillimit të ekzekutimit.
- Objektet e lidhjes së menjëhershme: A e lejon lidhësi i mjedisit të ekzekutimit të gjitha lëvizjet para fillimit të ekzekutimit të programit (kjo është ekuivalente me RELRO të plotë).
A janë mjaftueshme mekanizmat e mësipërm? Fatkeqësisht, jo. Janë të njohura mënyra për të anashkaluar të gjitha mbrojtjet e përmendura më lart, por sa më e fortë të jetë mbrojtja, aq më e lartë është barra për sulmuesin. Për shembull, janë më të vështira për t'u aplikuar nëse vepron PIE dhe lidhja e menjëhershme. Po ashtu, ASLR i plotë kërkon punë të shtuar për të krijuar një eksploit funksional. Megjithatë, sulmuesit e sofistikuar janë tashmë të gatshëm për të përballuar këto mbrojtje: mungesa e tyre në thelb do të përshpejtojë thyerjen. Prandaj, është jashtëzakonisht e rëndësishme që këto masa të shqyrtohen si të nevojshme. minimumi.
Ne donim të shqyrtonim se sa shumë skedarë binarë në shpërndarjet në shqyrtim janë të mbrojtur nga këto, si dhe nga tre metoda të tjera:
- Bitsi i pandërprerë () parandalon ekzekutimin në çdo rajon që nuk duhet të jetë ekzekutues, për shembull, në grumbullin e stack-ut etj.
- tregon rrugën e ekzekutimit, 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 tij i lejon sulmuesit të shkruajë lëndë në memorje dhe ta ekzekutojnë atë siç është. Për të dytën, konfigurimet e gabuara të rrugës së ekzekutimit ndihmojnë në futjen e kodit të pasigurt, i cili mund të çojë në një numër problemesh (p.sh., , si dhe ).
- Mbrojtja nga përplasje të stack-ut siguron mbrojtje nga sulmet që detyrojnë stack-un të përplaset me zona të tjera të memories (p.sh., heap-in). Duke marrë parasysh eksploitat e fundit që abuzojnë , ne e gjetëm të arsyeshme ta përfshijmë këtë mekanizëm në grupin tonë të të dhënave.
Pra, pa më shumë ceremoni, le të kalojmë në numra. Tabelat 4 dhe 5 përmbajnë një përmbledhje të analizës së skedarëve ekzekutivë dhe bibliotekave të shpërndarjeve të ndryshme, përkatësisht.
- Siç mund të vëreni, mbrojtja NX është implementuar përkrah çdo vendi, për excepcione të pakta. Saktësisht, mund të vërehet përdorimi disi më i ulët në shpërndarjet Ubuntu dhe Debian në krahasim me CentOS, RHEL dhe OpenSUSE.
- Stakot e kanarinave mungon në shumë vende, veçanërisht në shpërndarjet me bërthamë të vjetër. Disa përparim shihet në shpërndarjet e fundit të CentOS, RHEL, Debian dhe Ubuntu.
- Përveç Debian dhe Ubuntu 18.04, shumica e shpërndarjeve kanë mbështetje të dobët për PIE.
- Mbrojtja nga përplasjeve të stack-ut është keq e realizuar në OpenSUSE, CentOS 7 dhe RHEL 7 dhe praktikisht mungon te të tjerat.
- Të gjitha shpërndarjet me bërthama moderne kanë mbështetje të caktuar për RELRO, me lider Ubuntu 18.04, ndjekur nga Debian.
Siç u përmend më parë, metrikat në këtë tabelë janë mesatare për të gjitha versionet e skedarit binar. Nëse shikoni vetëm versionet e fundit të skedarëve, numrat do të jenë të ndryshëm (p.sh., shihni. ). Për më tepër, shumica e shpërndarjeve zakonisht në llogaritjen e statistikave verifikojnë mbrojtjen vetëm e disa funksioneve në kodin binar, ndërsa në analizën tonë tregohet përqindja e vërtetë e funksioneve të forcuara. Prandaj, nëse në binar janë të mbrojtura 5 nga 50 funksione, ne do i japim një vlerësim 0,1, që përkon me 10% të funksioneve të forcuara.
Tabela 4. Karakteristikat e mbrojtjes për skedarët ekzekutivë, që shihen në fig. 3 (implementimi i funksioneve përkatëse në përqindje të përgjithshme të numrit të skedarëve ekzekutivë)
Tabela 5. Karakteristikat e mbrojtjes për bibliotekat, që shihen në fig. 3 (implementimi i funksioneve përkatëse në përqindje të përgjithshme të numrit të bibliotekave)
A ka ndonjĂ« pĂ«rparim? Definitivisht po: kjo Ă«shtĂ« e dukshme nga statistikat mbi distribuimet e veçanta (p.sh., ), si dhe nga tabelat e mĂ«sipĂ«rme. Si njĂ« shembull, nĂ« fig. 6 ilustrohet implementimi i mekanizmave tĂ« mbrojtjes nĂ« tre distribuime tĂ« njĂ«pasnjĂ«shme tĂ« Ubuntu LTS 5 (ne e kemi lĂ«nĂ« jashtĂ« statistikĂ«n e mbrojtjes nga pĂ«rplasje tĂ« stackut). VĂ«rejmĂ« se nga ĐČĐ”ŃŃĐžŃ nĂ« version gjithnjĂ« e mĂ« shumĂ« skedarĂ« mbĂ«shtesin kanat e stackut, si dhe gjithnjĂ« e mĂ« shumĂ« skedarĂ« binarĂ« dorĂ«zohen me mbrojtje tĂ« plotĂ« RELRO.
Fig. 6
Fatkeq, disa ekzekutues të skedarëve në distributions të ndryshme vazhdojnë të mos ofrojnë asnjë nga mbrojtjet e përmendura më sipër. Për shembull, duke shqyrtuar Ubuntu 18.04, mund të vëresh binarin ngetty (zëvendësimi i getty), si dhe shell-at mksh dhe lksh, interpretuesin picolisp, paketat nvidia-cuda-toolkit (një paketë e njohur për aplikacione të mbështetura nga GPU, si framework-et e mësimit të makinerive) dhe klibc-utils. Po ashtu, binari mandos-client (një mjet administrativ që lejon rikthimin automatik të makinave me sisteme skedarësh të enkriptuar), si dhe rsh-redone-client (rilindja e rsh dhe rlogin) vijnë pa mbrojtjen NX, megjithëse kanë të drejta SUID :(. Për më tepër, disa binarë SUID nuk kanë mbrojtjen bazë, siç janë kanarët e stack-ut (për shembull, skedari binar Xorg.wrap nga paketa Xorg).
Përmbledhje dhe vërejtje përfundimtare
Në këtë artikull, kemi theksuar disa veçori të sigurisë së shpërndarjeve moderne të Linux-it. Analiza tregon se shpërndarja më e fundit LTS e Ubuntu (18.04) ka nivelin mesatar më të fortë të mbrojtjes në nivelin e OS dhe aplikacioneve, krahasuar me shpërndarje më të vjetra si Ubuntu 14.04, 12.04 dhe Debian 9. Sidoqoftë, shpërndarjet e shqyrtuara CentOS, RHEL dhe OpenSUSE në setin tonë të dhënash në mënyrë default ofrojnë një grup më të dendur paketash dhe në versionet më të fundit (CentOS dhe RHEL) kanë një përqindje më të lartë të zbatimit të mbrojtjes nga përplasje të stack-ut, në krahasim me konkurrentët e bazuar në Debian (Debian dhe Ubuntu). Duke krahasuar versionet CentOS dhe RedHat, vërejmë përmirësime të mëdha në zbatimin e kanaleve të stack-ut dhe RELRO nga versionet 6 në 7, por mesatarisht në CentOS janë implementuar më shumë veçori sesa në RHEL. Përmbledhtas, të gjitha shpërndarjet duhet të përkushtohen veçanërisht për mbrojtjen PIE, e cila, përveç Debian 9 dhe Ubuntu 18.04, është implementuar në më pak se 10% të skedave binarë nga seti ynë i të dhënave.
Në fund, duhet të theksohet: ndonëse ne e kryem hulumtimin manualisht, ekzistojnë shumë mjete sigurie (p.sh., , , ), të cilat analizojnë dhe ndihmojnë në shmangien e konfigurimeve të pasigurta. Fatkeqësisht, edhe mbrojtja më e fortë në konfigurimet e arsyeshme nuk garanton mungesën e eksploiteve. Kjo është arsyeja pse ne besojmë me vendosmëri se është jetike të sigurohen , duke u përqendruar në modelet e shfrytëzimit dhe duke i parandaluar ato.
Burimi: habr.com
