TL; DR. I denne artikel udforsker vi de hærdningsordninger, der fungerer ud af boksen på fem populære Linux-distributioner. For hver tog vi standardkernekonfigurationen, indlæste alle pakkerne og analyserede sikkerhedsskemaerne i de vedhæftede binære filer. De overvejede distributioner er OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 og 7 samt Ubuntu 14.04, 12.04 og 18.04 LTS.
Resultaterne bekræfter, at selv grundlæggende ordninger som stabling af kanariefugle og positionsuafhængig kode endnu ikke er vedtaget af alle. Situationen er endnu værre for compilere, når det kommer til at beskytte mod sårbarheder som stack clash, der kom i søgelyset i januar efter offentliggørelse . Men ikke alt er så håbløst. Et betydeligt antal binære filer implementerer grundlæggende beskyttelsesmetoder, og deres antal vokser fra version til version.
Gennemgangen viste, at det største antal beskyttelsesmetoder er implementeret i Ubuntu 18.04 på OS og applikationsniveauer, efterfulgt af Debian 9. På den anden side implementerer OpenSUSE 12.4, CentOS 7 og RHEL 7 også grundlæggende beskyttelsesordninger og stakkollisionsbeskyttelse bruges endnu mere udbredt med et meget tættere sæt standardpakker.
Indledning
Det er svært at sikre software af høj kvalitet. På trods af det store antal avancerede værktøjer til statisk kodeanalyse og dynamisk runtime-analyse, samt betydelige fremskridt i udviklingen af compilere og programmeringssprog, lider moderne software stadig af sårbarheder, der konstant udnyttes af angribere. Situationen er endnu værre i økosystemer, der inkluderer ældre kode. I sådanne tilfælde står vi ikke kun over for det evige problem med at finde mulige udnyttelige fejl, men vi er også begrænset af strenge bagudkompatibilitetsrammer, som ofte kræver, at vi bevarer begrænset, eller endnu værre, sårbar eller buggy-kode.
Det er her metoder til at beskytte eller hærde programmer kommer i spil. Vi kan ikke forhindre nogle typer fejl, men vi kan gøre angriberens liv sværere og delvist løse problemet ved at forhindre eller forhindre operation disse fejl. En sådan beskyttelse bruges i alle moderne operativsystemer, men metoderne adskiller sig meget i kompleksitet, effektivitet og ydeevne: fra stakkanariefugle og til fuld beskyttelse и . I denne artikel vil vi se på, hvilke beskyttelsesmetoder der bruges i de mest populære Linux-distributioner i standardkonfigurationen, og vi vil også undersøge egenskaberne for de binære filer, der distribueres gennem hver distributions pakkehåndteringssystem.
CVE og sikkerhed
Vi har alle set artikler med titler som "Årets mest sårbare applikationer" eller "De mest sårbare operativsystemer." Normalt leverer de statistik over det samlede antal registreringer om sårbarheder som f.eks , Opnået fra fra og andre kilder. Efterfølgende rangeres disse applikationer eller OS efter antallet af CVE'er. Selvom CVE'er er meget nyttige til at spore problemer og informere leverandører og brugere, siger de desværre lidt om softwarens faktiske sikkerhed.
Som et eksempel kan du overveje det samlede antal CVE'er i løbet af de sidste fire år for Linux-kernen og de fem mest populære serverdistributioner, nemlig Ubuntu, Debian, Red Hat Enterprise Linux og OpenSUSE.
Fig. 1
Hvad fortæller denne graf os? Betyder et højere antal CVE'er, at en distribution er mere sårbar end en anden? Intet svar. For eksempel vil du i denne artikel se, at Debian har stærkere sikkerhedsmekanismer sammenlignet med for eksempel OpenSUSE eller RedHat Linux, og alligevel har Debian flere CVE'er. Men de betyder ikke nødvendigvis svækket sikkerhed: selv tilstedeværelsen af en CVE indikerer ikke, om en sårbarhed er udnyttet. Sværhedsgrad giver en indikation af hvordan sandsynligvis udnyttelse af en sårbarhed, men i sidste ende afhænger udnyttelse i høj grad af den beskyttelse, der findes i de berørte systemer, og angribernes ressourcer og muligheder. Desuden siger fraværet af CVE-rapporter intet om andre uregistreret eller ukendt sårbarheder. Forskellen i CVE kan skyldes andre faktorer end softwarekvalitet, herunder de ressourcer, der er allokeret til test eller størrelsen af brugerbasen. I vores eksempel kan Debians højere antal CVE'er simpelthen indikere, at Debian sender flere softwarepakker.
Selvfølgelig giver CVE-systemet nyttig information, der giver dig mulighed for at oprette passende beskyttelser. Jo bedre vi forstår årsagerne til programfejl, jo lettere er det at identificere mulige udnyttelsesmetoder og udvikle passende mekanismer detektion og respons. I fig. 2 viser kategorierne af sårbarheder for alle distributioner over de sidste fire år (). Det er umiddelbart klart, at de fleste CVE'er falder ind under følgende kategorier: lammelsesangreb (DoS), kodeudførelse, overløb, hukommelseskorruption, informationslækage (eksfiltrering) og privilegieeskalering. Selvom mange CVE'er tælles flere gange i forskellige kategorier, fortsætter de samme problemer generelt år efter år. I den næste del af artiklen vil vi evaluere brugen af forskellige beskyttelsesordninger for at forhindre udnyttelsen af disse sårbarheder.
Fig. 2
opgaver
I denne artikel vil vi besvare følgende spørgsmål:
- Hvad er sikkerheden ved forskellige Linux-distributioner? Hvilke beskyttelsesmekanismer findes i kerne- og brugerrumsapplikationerne?
- Hvordan har vedtagelsen af sikkerhedsmekanismer ændret sig over tid på tværs af distributioner?
- Hvad er de gennemsnitlige afhængigheder af pakker og biblioteker for hver distribution?
- Hvilke beskyttelser implementeres for hver binær?
Udvalg af distributioner
Det viser sig, at det er svært at finde præcise statistikker over distributionsinstallationer, da antallet af downloads i de fleste tilfælde ikke angiver antallet af faktiske installationer. Unix-varianter udgør dog størstedelen af serversystemerne (på webservere 69,2 %, ca W3techs og andre kilder), og deres andel vokser konstant. For vores forskning fokuserede vi således på distributioner, der var tilgængelige direkte fra boksen på platformen . Vi valgte især følgende OS:
Distribution/version
Kernen
Byg
OpenSUSE 12.4
4.12.14-95.3-standard
#1 SMP ons 5. december 06:00:48 UTC 2018 (63a8d29)
Debian 9 (stræk)
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 Tue Jan 15 17:07:28 UTC 2019
7 CentOS
3.10.0-957.5.1.el7.x86_64
#1 SMP Fre 1 Feb 14:54:57 UTC 2019
Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP ons 21. nov. 15:08:21 EST 2018
Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP tor 15. nov 17:36:42 UTC 2018
Ubuntu 14.04 (Trusty Tahr)
4.4.0-140-generisk
#166~14.04.1-Ubuntu SMP Lør 17. nov 01:52:43 UTC 20...
Ubuntu 16.04 (Xenial Xerus)
4.15.0-1026-gcp
#27~16.04.1-Ubuntu SMP fre 7. dec. 09:59:47 UTC 2018
Ubuntu 18.04 (Bionic Beaver)
4.15.0-1026-gcp
#27-Ubuntu SMP tor 6. dec. 18:27:01 UTC 2018
Tabel 1
Analyse
Lad os studere standardkernekonfigurationen såvel som egenskaberne for pakker, der er tilgængelige via pakkehåndteringen for hver distribution ud af kassen. Derfor betragter vi kun pakker fra hver distributions standardspejle, idet vi ignorerer pakker fra ustabile arkiver (såsom Debians 'testende' spejle) og tredjepartspakker (såsom Nvidia-pakker fra standardspejle). Derudover overvejer vi ikke tilpassede kernekompilationer eller sikkerhedshærdede konfigurationer.
Kernekonfigurationsanalyse
Vi anvendte et analysescript baseret på . Lad os se på de out-of-the-box beskyttelsesparametre for de navngivne distributioner og sammenligne dem med listen fra (KSPP). For hver konfigurationsmulighed beskriver Tabel 2 den ønskede indstilling: afkrydsningsfeltet er for distributioner, der overholder KSSP-anbefalingerne (se det følgende for en forklaring af begreber). ; I fremtidige artikler vil vi forklare, hvor mange af disse sikkerhedsmetoder, der blev til, og hvordan man hacker et system i deres fravær).
Generelt har de nye kerner strengere indstillinger ud af boksen. For eksempel mangler CentOS 6.10 og RHEL 6.10 på 2.6.32 kernen de fleste af de kritiske funktioner implementeret i nyere kerner som f.eks. , strenge RWX-tilladelser, adresserandomisering eller copy2usr-beskyttelse. Det skal bemærkes, at mange af konfigurationsmulighederne i tabellen ikke er tilgængelige i ældre versioner af kernen og ikke er anvendelige i virkeligheden - dette er stadig angivet i tabellen som en mangel på ordentlig beskyttelse. Ligeledes, hvis en konfigurationsmulighed ikke er til stede i en given version, og sikkerheden kræver, at denne mulighed er deaktiveret, betragtes dette som en rimelig konfiguration.
Et andet punkt at overveje, når resultaterne fortolkes: nogle kernekonfigurationer, der øger angrebsoverfladen, kan også bruges til sikkerhed. Sådanne eksempler inkluderer uprober og kprobes, kernemoduler og BPF/eBPF. Vores anbefaling er at bruge ovenstående mekanismer til at give reel beskyttelse, da de er ikke-trivielle at bruge og deres udnyttelse forudsætter, at ondsindede aktører allerede har fået fodfæste i systemet. Men hvis disse muligheder er aktiveret, skal systemadministratoren aktivt overvåge for misbrug.
Ser vi videre på indtastningerne i tabel 2, ser vi, at moderne kerner giver flere muligheder for at beskytte mod udnyttelse af sårbarheder såsom informationslækage og stack/heap-overløb. Vi bemærker dog, at selv de seneste populære distributioner endnu ikke har implementeret mere kompleks beskyttelse (for eksempel med patches ) eller moderne beskyttelse mod kodegenbrugsangreb (f.eks. ). For at gøre tingene værre, beskytter selv disse mere avancerede forsvar ikke mod hele spektret af angreb. Derfor er det afgørende for systemadministratorer at supplere smarte konfigurationer med løsninger, der tilbyder registrering og forebyggelse af runtime-udnyttelse.
Applikationsanalyse
Ikke overraskende har forskellige distributioner forskellige pakkekarakteristika, kompileringsmuligheder, biblioteksafhængigheder osv. Der er forskelle selv for distributioner og pakker med et lille antal afhængigheder (for eksempel coreutils på Ubuntu eller Debian). For at evaluere forskellene downloadede vi alle tilgængelige pakker, udtrak deres indhold og analyserede binære filer og afhængigheder. For hver pakke holdt vi styr på de andre pakker, den afhænger af, og for hver binær, sporede vi dens afhængigheder. I dette afsnit opsummerer vi kort konklusionerne.
distributioner
I alt downloadede vi 361 pakker til alle distributioner og udtrak kun pakker fra standardspejle. Vi ignorerede pakker uden ELF-eksekverbare filer, såsom kilder, skrifttyper osv. Efter filtrering var der 556 pakker tilbage, indeholdende i alt 129 binære filer. Fordelingen af pakker og filer på tværs af distributioner er vist i fig. 569.
Fig. 3
Du bemærker måske, at jo mere moderne distributionen er, jo flere pakker og binære filer indeholder den, hvilket er logisk. Ubuntu og Debian-pakker inkluderer dog mange flere binære filer (både eksekverbare og dynamiske moduler og biblioteker) end CentOS, SUSE og RHEL, hvilket potentielt påvirker angrebsoverfladen på Ubuntu og Debian (det skal bemærkes, at tallene afspejler alle binære filer af alle versioner pakke, det vil sige, at nogle filer analyseres flere gange). Dette er især vigtigt, når du overvejer afhængigheder mellem pakker. En sårbarhed i en enkelt pakke binær kan således påvirke mange dele af økosystemet, ligesom et sårbart bibliotek kan påvirke alle binære filer, der importerer det. Lad os som udgangspunkt se på fordelingen af antallet af afhængigheder mellem pakker i forskellige operativsystemer:
Fig. 4
I næsten alle distributioner har 60 % af pakkerne mindst 10 afhængigheder. Derudover har nogle pakker et betydeligt større antal afhængigheder (mere end 100). Det samme gælder for omvendte pakkeafhængigheder: Som forventet bruges nogle få pakker af mange andre pakker i distributionen, så sårbarheder i disse udvalgte få er højrisiko. Som et eksempel viser følgende tabel de 20 pakker med det maksimale antal omvendte afhængigheder i SLES, Centos 7, Debian 9 og Ubuntu 18.04 (hver celle angiver pakken og antallet af omvendte afhængigheder).
Tabel 3
Interessant fakta. Selvom alle analyserede operativsystemer er bygget til x86_64-arkitekturen, og de fleste pakker har arkitekturen defineret som x86_64 og x86, indeholder pakker ofte binære filer til andre arkitekturer, som vist i figur 5. XNUMX.
Fig. 5
I næste afsnit vil vi dykke ned i karakteristikaene for de analyserede binære filer.
Binær filbeskyttelsesstatistik
Som det absolutte minimum skal du udforske et grundlæggende sæt sikkerhedsindstillinger for dine eksisterende binære filer. Adskillige Linux-distributioner leveres med scripts, der udfører sådanne kontroller. For eksempel har Debian/Ubuntu et sådant script. Her er et eksempel på hans arbejde:
$ 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: yesScriptet tjekker fem :
- Position Independent Executable (PIE): Angiver om tekstsektionen af et program kan flyttes i hukommelsen for at opnå randomisering, hvis ASLR er aktiveret i kernen.
- Stack Protected: Om stakkanariefugle er aktiveret for at beskytte mod stakkollisionsangreb.
- Fortify Source: om usikre funktioner (f.eks. strcpy) erstattes med deres mere sikre modstykker, og opkald, der kontrolleres under kørsel, erstattes med deres ukontrollerede modparter (f.eks. memcpy i stedet for __memcpy_chk).
- Skrivebeskyttede flytninger (RELRO): Om flyttabelposter er markeret som skrivebeskyttet, hvis de udløses før udførelsen begynder.
- Øjeblikkelig binding: Om runtime-linkeren tillader alle bevægelser, før programafviklingen begynder (dette svarer til en fuld RELRO).
Er ovenstående mekanismer tilstrækkelige? Desværre ikke. Der er kendte måder at omgå alle ovenstående forsvar, men jo hårdere forsvar, jo højere er baren for angriberen. For eksempel, vanskeligere at anvende, hvis PIE og øjeblikkelig binding er i kraft. Ligeledes kræver fuld ASLR yderligere arbejde for at skabe en fungerende udnyttelse. Men sofistikerede angribere er allerede parat til at opfylde sådanne beskyttelser: deres fravær vil i det væsentlige fremskynde hacket. Det er derfor vigtigt, at disse foranstaltninger anses for nødvendige mindste.
Vi ønskede at undersøge, hvor mange binære filer i de pågældende distributioner, der er beskyttet af disse og tre andre metoder:
- Ikke-eksekverbar bit () forhindrer eksekvering i enhver region, der ikke burde være eksekverbar, såsom stack-heapen osv.
- angiver den udførelsessti, der bruges af den dynamiske loader til at finde matchende biblioteker. Den første er obligatorisk for ethvert moderne system: dets fravær tillader angribere vilkårligt at skrive nyttelasten ind i hukommelsen og udføre den, som den er. For det andet hjælper forkerte udførelsesstikonfigurationer med at introducere upålidelig kode, der kan føre til en række problemer (f.eks. og ).
- Stakkollisionsbeskyttelse giver beskyttelse mod angreb, der får stakken til at overlappe andre områder af hukommelsen (såsom heapen). I betragtning af de seneste udnyttelser misbrug , mente vi, at det var passende at inkludere denne mekanisme i vores datasæt.
Så lad os uden videre komme ned til tallene. Tabel 4 og 5 indeholder en oversigt over analysen af henholdsvis eksekverbare filer og biblioteker af forskellige distributioner.
- Som du kan se, er NX-beskyttelse implementeret overalt, med sjældne undtagelser. Især kan man bemærke dets lidt lavere brug i Ubuntu og Debian-distributioner sammenlignet med CentOS, RHEL og OpenSUSE.
- Stakkanariefugle mangler mange steder, især i distributioner med ældre kerner. Der ses nogle fremskridt i de seneste distributioner af Centos, RHEL, Debian og Ubuntu.
- Med undtagelse af Debian og Ubuntu 18.04 har de fleste distributioner dårlig PIE-understøttelse.
- Stakkollisionsbeskyttelse er svag i OpenSUSE, Centos 7 og RHEL 7 og næsten ikke-eksisterende i andre.
- Alle distributioner med moderne kerner har en vis støtte til RELRO, hvor Ubuntu 18.04 fører an, og Debian kommer på andenpladsen.
Som allerede nævnt er metrikkerne i denne tabel gennemsnittet for alle versioner af den binære fil. Hvis du kun ser på de seneste versioner af filer, vil tallene være anderledes (se f.eks ). Desuden tester de fleste distributioner typisk kun sikkerheden af nogle få funktioner i binæren ved beregning af statistik, men vores analyse viser den sande procentdel af funktioner, der er hærdet. Derfor, hvis 5 ud af 50 funktioner er beskyttet i en binær, vil vi give den en score på 0,1, hvilket svarer til, at 10 % af funktionerne styrkes.
Tabel 4. Sikkerhedsegenskaber for de eksekverbare filer vist i fig. 3 (implementering af relevante funktioner som en procentdel af det samlede antal eksekverbare filer)
Tabel 5. Sikkerhedsegenskaber for bibliotekerne vist i fig. 3 (implementering af relevante funktioner i procent af det samlede antal biblioteker)
Så er der fremskridt? Det er der bestemt: dette kan ses fra statistikken for individuelle fordelinger (f.eks. ), samt fra tabellerne ovenfor. Som et eksempel i fig. Figur 6 viser implementeringen af beskyttelsesmekanismer i tre på hinanden følgende distributioner af Ubuntu LTS 5 (vi har udeladt statistik over stakkollisionsbeskyttelse). Vi bemærker, at fra version til version understøtter flere og flere filer stack canaries, og også flere og flere binære filer sendes med fuld RELRO-beskyttelse.
Fig. 6
Desværre har en række eksekverbare filer i forskellige distributioner stadig ikke nogen af ovenstående beskyttelser. Hvis du for eksempel ser på Ubuntu 18.04, vil du bemærke ngetty-binæren (en getty-erstatning) såvel som mksh- og lksh-skallene, picolisp-fortolkeren, nvidia-cuda-toolkit-pakkerne (en populær pakke til GPU-accelererede applikationer såsom maskinlæringsrammer) og klibc -utils. Ligeledes sendes mandos-client binær (et administrativt værktøj, der giver dig mulighed for automatisk at genstarte maskiner med krypterede filsystemer) samt rsh-redone-client (en genimplementering af rsh og rlogin) uden NX-beskyttelse, selvom de har SUID-rettigheder: (. Også adskillige suid-binære filer mangler grundlæggende beskyttelse, såsom stakkanariefugle (f.eks. Xorg.wrap-binæren fra Xorg-pakken).
Sammenfatning og afsluttende bemærkninger
I denne artikel har vi fremhævet flere sikkerhedsfunktioner i moderne Linux-distributioner. Analysen viste, at den seneste Ubuntu LTS-distribution (18.04) i gennemsnit implementerer den stærkeste OS- og applikationsniveaubeskyttelse blandt distributioner med relativt nye kerner, såsom Ubuntu 14.04, 12.04 og Debian 9. De undersøgte distributioner CentOS, RHEL og OpenSUSE i vores sæt producerer som standard et tættere sæt pakker, og i de seneste versioner (CentOS og RHEL) har de en højere procentdel af stakkollisionsbeskyttelse sammenlignet med Debian-baserede konkurrenter (Debian og Ubuntu). Ved at sammenligne CentOS- og RedHat-versioner bemærker vi store forbedringer i implementeringen af stack canaries og RELRO fra version 6 til 7, men i gennemsnit har CentOS flere funktioner implementeret end RHEL. Generelt bør alle distributioner være særligt opmærksomme på PIE-beskyttelse, som med undtagelse af Debian 9 og Ubuntu 18.04 er implementeret i mindre end 10 % af de binære filer i vores datasæt.
Endelig skal det bemærkes, at selvom vi udførte undersøgelsen manuelt, er der mange tilgængelige sikkerhedsværktøjer (f. , , ), som udfører analyser og hjælper med at undgå usikre konfigurationer. Desværre garanterer selv stærk beskyttelse i rimelige konfigurationer ikke fraværet af udnyttelser. Derfor er vi overbevist om, at det er afgørende at sikre , med fokus på udnyttelsesmønstre og forebyggelse af dem.
Kilde: www.habr.com