TL; DR. I denne artikkelen utforsker vi herdingsordningene som fungerer ut av boksen på fem populære Linux-distribusjoner. For hver tok vi standard kjernekonfigurasjon, lastet inn alle pakkene og analyserte sikkerhetsskjemaene i de vedlagte binærfilene. Distribusjonene som vurderes er OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 og 7, samt Ubuntu 14.04, 12.04 og 18.04 LTS.

Resultatene bekrefter at selv grunnleggende ordninger som stabling av kanarifugler og posisjonsuavhengig kode ennå ikke er tatt i bruk av alle. Situasjonen er enda verre for kompilatorer når det gjelder å beskytte mot sårbarheter som stack clash, som kom i søkelyset i januar etter publisering informasjon om systemsårbarheter. Men ikke alt er så håpløst. Et betydelig antall binærfiler implementerer grunnleggende beskyttelsesmetoder, og antallet vokser fra versjon til versjon.

Gjennomgangen viste at det største antallet beskyttelsesmetoder er implementert i Ubuntu 18.04 på OS- og applikasjonsnivå, etterfulgt av Debian 9. På den annen side implementerer OpenSUSE 12.4, CentOS 7 og RHEL 7 grunnleggende beskyttelsesordninger, og stackkollisjonsbeskyttelse brukes enda mer utbredt med et mye tettere sett med standardpakker.

Innledning

Det er vanskelig å sikre høykvalitets programvare. Til tross for det store antallet avanserte verktøy for statisk kodeanalyse og dynamisk kjøretidsanalyse, samt betydelig fremgang i utviklingen av kompilatorer og programmeringsspråk, lider moderne programvare fortsatt av sårbarheter som stadig utnyttes av angripere. Situasjonen er enda verre i økosystemer som inkluderer eldre kode. I slike tilfeller står vi ikke bare overfor det evige problemet med å finne mulige utnyttbare feil, men vi er også begrenset av strenge bakoverkompatibilitetsrammeverk, som ofte krever at vi bevarer begrenset, eller enda verre, sårbar eller buggy-kode.

Det er her metoder for å beskytte eller herde programmer kommer inn i bildet. Vi kan ikke forhindre noen typer feil, men vi kan gjøre angriperens liv vanskeligere og delvis løse problemet ved å forhindre eller forhindre utnyttelse disse feilene. Slik beskyttelse brukes i alle moderne operativsystemer, men metodene varierer sterkt i kompleksitet, effektivitet og ytelse: fra stablekanarifugler og ASLR til full beskyttelse CFI и ROP. I denne artikkelen vil vi se på hvilke beskyttelsesmetoder som brukes i de mest populære Linux-distribusjonene i standardkonfigurasjonen, og også undersøke egenskapene til binærfilene som distribueres gjennom pakkehåndteringssystemene til hver distribusjon.

CVE og sikkerhet

Vi har alle sett artikler med titler som "Årets mest sårbare applikasjoner" eller "De mest sårbare operativsystemene." Vanligvis gir de statistikk over det totale antallet poster om sårbarheter som CVE (Common Vulnerability and Exposures), hentet fra Nasjonal sårbarhetsdatabase (NVD) fra NIST og andre kilder. Deretter blir disse applikasjonene eller OS rangert etter antall CVEer. Selv om CVE-er er svært nyttige for å spore problemer og informere leverandører og brukere, sier de dessverre lite om den faktiske sikkerheten til programvaren.

Som et eksempel kan du vurdere det totale antallet CVEer de siste fire årene for Linux-kjernen og de fem mest populære serverdistribusjonene, nemlig Ubuntu, Debian, Red Hat Enterprise Linux og OpenSUSE.

Fig. 1

Hva forteller denne grafen oss? Betyr et høyere antall CVEer at en distribusjon er mer sårbar enn en annen? Ingen svar. For eksempel, i denne artikkelen vil du se at Debian har sterkere sikkerhetsmekanismer sammenlignet med for eksempel OpenSUSE eller RedHat Linux, og likevel har Debian flere CVE-er. Men de betyr ikke nødvendigvis svekket sikkerhet: selv tilstedeværelsen av en CVE indikerer ikke om en sårbarhet er utnyttet. Alvorlighetspoeng gir en indikasjon på hvordan sannsynligvis utnyttelse av en sårbarhet, men til syvende og sist avhenger utnyttelsesevnen sterkt av beskyttelsen som finnes i de berørte systemene og ressursene og evnene til angriperne. Dessuten sier fraværet av CVE-rapporter ingenting om andre uregistrert eller ukjent sårbarheter. Forskjellen i CVE kan skyldes andre faktorer enn programvarekvalitet, inkludert ressursene som er allokert til testing eller størrelsen på brukerbasen. I vårt eksempel kan Debians høyere antall CVE-er ganske enkelt indikere at Debian sender flere programvarepakker.

Selvfølgelig gir CVE-systemet nyttig informasjon som lar deg lage passende beskyttelser. Jo bedre vi forstår årsakene til programfeil, jo lettere er det å identifisere mulige utnyttelsesmetoder og utvikle passende mekanismer deteksjon og respons. I fig. 2 viser kategoriene av sårbarheter for alle distribusjoner de siste fire årene (kilde). Det er umiddelbart klart at de fleste CVE-er faller inn i følgende kategorier: tjenestenekt (DoS), kodekjøring, overløp, minnekorrupsjon, informasjonslekkasje (eksfiltrering) og rettighetseskalering. Selv om mange CVE-er telles flere ganger i forskjellige kategorier, vedvarer generelt de samme problemene år etter år. I neste del av artikkelen vil vi evaluere bruken av ulike beskyttelsesordninger for å forhindre utnyttelse av disse sårbarhetene.

Fig. 2

oppgaver

I denne artikkelen har vi tenkt å svare på følgende spørsmål:

• Hva er sikkerheten til forskjellige Linux-distribusjoner? Hvilke beskyttelsesmekanismer finnes i kjerne- og brukerromsapplikasjonene?
• Hvordan har bruken av sikkerhetsmekanismer endret seg over tid på tvers av distribusjoner?
• Hva er de gjennomsnittlige avhengighetene til pakker og biblioteker for hver distribusjon?
• Hvilke beskyttelser er implementert for hver binær?

Utvalg av distribusjoner

Det viser seg at det er vanskelig å finne nøyaktig statistikk over distribusjonsinstallasjoner, siden antallet nedlastinger i de fleste tilfeller ikke indikerer antall faktiske installasjoner. Unix-varianter utgjør imidlertid flertallet av serversystemer (på webservere 69,2 %, ca statistikk W3techs og andre kilder), og deres andel vokser stadig. Derfor, for vår forskning, fokuserte vi på distribusjoner tilgjengelig rett ut av esken på plattformen Google Cloud. Spesielt valgte vi følgende OS:

Distribusjon/versjon
Kjernen
Bygge

OpenSUSE 12.4
4.12.14-95.3-standard
#1 SMP ons 5. desember 06:00:48 UTC 2018 (63a8d29)

Debian 9 (strekk)
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. februar 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. november 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. november 01:52:43 UTC 20...

Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP fre 7. desember 09:59:47 UTC 2018

Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27-Ubuntu SMP tor 6. desember 18:27:01 UTC 2018

Tabell 1

Analyse

La oss studere standard kjernekonfigurasjon, samt egenskapene til pakker som er tilgjengelige gjennom pakkebehandleren for hver distribusjon ut av esken. Derfor tar vi kun i betraktning pakker fra hver distribusjons standardspeil, og ignorerer pakker fra ustabile arkiver (som Debian 'testing' speil) og tredjepartspakker (som Nvidia-pakker fra standard speil). I tillegg vurderer vi ikke tilpassede kjernekompilasjoner eller sikkerhetsherdede konfigurasjoner.

Kjernekonfigurasjonsanalyse

Vi brukte et analyseskript basert på gratis kconfig-sjekker. La oss se på ut-av-boksen beskyttelsesparametere for de navngitte distribusjonene og sammenligne dem med listen fra Kjerne selvforsvarsprosjekt (KSPP). For hvert konfigurasjonsalternativ beskriver tabell 2 ønsket innstilling: avkrysningsboksen er for distribusjoner som samsvarer med KSSP-anbefalingene (se følgende for en forklaring av begreper). her; I fremtidige artikler vil vi forklare hvor mange av disse sikkerhetsmetodene ble til og hvordan man hacker et system i deres fravær).

Generelt har de nye kjernene strengere innstillinger ut av esken. For eksempel mangler CentOS 6.10 og RHEL 6.10 på 2.6.32-kjernen de fleste av de kritiske funksjonene implementert i nyere kjerner som f.eks. SMAP, strenge RWX-tillatelser, adresserandomisering eller copy2usr-beskyttelse. Det skal bemerkes at mange av konfigurasjonsalternativene i tabellen ikke er tilgjengelige i eldre versjoner av kjernen og ikke er anvendelige i virkeligheten - dette er fortsatt indikert i tabellen som mangel på riktig beskyttelse. På samme måte, hvis et konfigurasjonsalternativ ikke er til stede i en gitt versjon, og sikkerheten krever at alternativet er deaktivert, anses dette som en rimelig konfigurasjon.

Et annet poeng å vurdere når du tolker resultatene: noen kjernekonfigurasjoner som øker angrepsoverflaten kan også brukes for sikkerhet. Slike eksempler inkluderer uprober og kprobes, kjernemoduler og BPF/eBPF. Vår anbefaling er å bruke mekanismene ovenfor for å gi reell beskyttelse, da de er ikke-trivielle å bruke og utnyttelsen av dem forutsetter at ondsinnede aktører allerede har etablert fotfeste i systemet. Men hvis disse alternativene er aktivert, må systemadministratoren aktivt overvåke for misbruk.

Ser vi videre på oppføringene i tabell 2, ser vi at moderne kjerner gir flere alternativer for å beskytte mot utnyttelse av sårbarheter som informasjonslekkasje og stack/heap overflows. Vi legger imidlertid merke til at selv de nyeste populære distribusjonene ennå ikke har implementert mer kompleks beskyttelse (for eksempel med patcher grsikkerhet) eller moderne beskyttelse mot kodegjenbruksangrep (f.eks. kombinasjon av randomisering med skjemaer som R^X for kode). For å gjøre vondt verre, beskytter ikke selv disse mer avanserte forsvarene mot hele spekteret av angrep. Derfor er det avgjørende for systemadministratorer å komplettere smarte konfigurasjoner med løsninger som tilbyr gjenkjenning og forebygging av runtime-utnyttelse.

Applikasjonsanalyse

Ikke overraskende har forskjellige distribusjoner forskjellige pakkekarakteristikker, kompileringsalternativer, bibliotekavhengigheter osv. Det finnes forskjeller selv for i slekt distribusjoner og pakker med et lite antall avhengigheter (for eksempel coreutils på Ubuntu eller Debian). For å evaluere forskjellene lastet vi ned alle tilgjengelige pakker, hentet ut innholdet og analyserte binærene og avhengighetene. For hver pakke holdt vi styr på de andre pakkene den er avhengig av, og for hver binær, sporet vi avhengighetene. I denne delen oppsummerer vi kort konklusjonene.

Distribusjoner

Totalt lastet vi ned 361 556 pakker for alle distribusjoner, og hentet kun pakker fra standardspeil. Vi ignorerte pakker uten kjørbare ELF-filer, som kilder, fonter osv. Etter filtrering gjensto 129 569 pakker, med totalt 584 457 binærfiler. Distribusjonen av pakker og filer på tvers av distribusjoner er vist i fig. 3.

Fig. 3

Du vil kanskje legge merke til at jo mer moderne distribusjonen er, jo flere pakker og binærfiler inneholder den, noe som er logisk. Ubuntu- og Debian-pakker inkluderer imidlertid mange flere binærfiler (både kjørbare og dynamiske moduler og biblioteker) enn CentOS, SUSE og RHEL, som potensielt påvirker angrepsoverflaten til Ubuntu og Debian (det bør bemerkes at tallene gjenspeiler alle binærfiler av alle versjoner pakke, det vil si at noen filer analyseres flere ganger). Dette er spesielt viktig når du vurderer avhengigheter mellom pakker. Dermed kan en sårbarhet i en enkelt pakke-binærfil påvirke mange deler av økosystemet, akkurat som et sårbart bibliotek kan påvirke alle binære filer som importerer det. Som et utgangspunkt, la oss se på fordelingen av antall avhengigheter mellom pakker i forskjellige operativsystemer:

Fig. 4

I nesten alle distribusjoner har 60 % av pakkene minst 10 avhengigheter. I tillegg har noen pakker et betydelig større antall avhengigheter (mer enn 100). Det samme gjelder omvendte pakkeavhengigheter: Som forventet brukes noen få pakker av mange andre pakker i distribusjonen, så sårbarheter i de få utvalgte er høyrisiko. Som et eksempel viser følgende tabell de 20 pakkene med maksimalt antall omvendte avhengigheter i SLES, Centos 7, Debian 9 og Ubuntu 18.04 (hver celle angir pakken og antall omvendte avhengigheter).

Tabell 3

Interessant fakta. Selv om alle OS-er som er analysert er bygget for x86_64-arkitekturen, og de fleste pakker har arkitekturen definert som x86_64 og x86, inneholder pakker ofte binærfiler for andre arkitekturer, som vist i figur 5. XNUMX.

Fig. 5

I neste avsnitt skal vi fordype oss i egenskapene til de analyserte binærfilene.

Binær filbeskyttelsesstatistikk

Som et absolutt minimum må du utforske et grunnleggende sett med sikkerhetsalternativer for dine eksisterende binærfiler. Flere Linux-distribusjoner kommer med skript som utfører slike kontroller. For eksempel har Debian/Ubuntu et slikt skript. Her er et eksempel på arbeidet hans:

$ 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: yes

Manuset sjekker fem beskyttelsesfunksjoner:

• Position Independent Executable (PIE): Angir om tekstdelen av et program kan flyttes i minnet for å oppnå randomisering hvis ASLR er aktivert i kjernen.
• Stabelbeskyttet: Om stabelkanarifugler er aktivert for å beskytte mot stabelkollisjonsangrep.
• Fortify Source: om usikre funksjoner (for eksempel strcpy) erstattes med sine sikrere motparter, og anrop som er sjekket under kjøretid, erstattes med deres ukontrollerte motparter (for eksempel memcpy i stedet for __memcpy_chk).
• Skrivebeskyttede flyttinger (RELRO): Om flyttingstabelloppføringer er merket som skrivebeskyttet hvis de utløses før kjøringen begynner.
• Umiddelbar binding: Om runtime-linkeren tillater alle bevegelser før programkjøringen begynner (dette tilsvarer en full RELRO).

Er mekanismene ovenfor tilstrekkelige? Dessverre ikke. Det er kjente måter å omgå alle de ovennevnte forsvarene på, men jo tøffere forsvar, jo høyere er baren for angriperen. For eksempel, RELRO bypass metoder vanskeligere å bruke hvis PIE og umiddelbar binding er i kraft. På samme måte krever full ASLR ekstra arbeid for å skape en fungerende utnyttelse. Imidlertid er sofistikerte angripere allerede forberedt på å møte slike beskyttelser: deres fravær vil i hovedsak fremskynde hacket. Det er derfor vesentlig at disse tiltakene anses som nødvendige minimum.

Vi ønsket å studere hvor mange binære filer i de aktuelle distribusjonene som er beskyttet av disse og tre andre metoder:

• Ukjørbar bit (NX) forhindrer kjøring i enhver region som ikke skal være kjørbar, for eksempel stabelhaugen osv.
• RPATH/RUNPATH angir utførelsesbanen som brukes av den dynamiske lasteren for å finne samsvarende biblioteker. Den første er obligatorisk for ethvert moderne system: fraværet tillater angripere å vilkårlig skrive nyttelasten inn i minnet og kjøre den som den er. For det andre hjelper feil utførelsesbanekonfigurasjoner med å introdusere upålitelig kode som kan føre til en rekke problemer (f.eks. privilegieeskaleringOg andre problemer).
• Stabelkollisjonsbeskyttelse gir beskyttelse mot angrep som får stabelen til å overlappe andre områder av minnet (som haugen). Gitt nylige utnyttelser misbruk systemd heap-kollisjonssårbarheter, mente vi det var hensiktsmessig å inkludere denne mekanismen i datasettet vårt.

Så, uten videre, la oss komme ned til tallene. Tabell 4 og 5 inneholder et sammendrag av analysen av henholdsvis kjørbare filer og biblioteker for ulike distribusjoner.

• Som du kan se, er NX-beskyttelse implementert overalt, med sjeldne unntak. Spesielt kan man merke seg den litt lavere bruken i Ubuntu- og Debian-distribusjoner sammenlignet med CentOS, RHEL og OpenSUSE.
• Stabelkanarifugler mangler mange steder, spesielt i distribusjoner med eldre kjerner. En viss fremgang kan sees i de siste distribusjonene av Centos, RHEL, Debian og Ubuntu.
• Med unntak av Debian og Ubuntu 18.04, har de fleste distribusjoner dårlig PIE-støtte.
• Stabelkollisjonsbeskyttelse er svak i OpenSUSE, Centos 7 og RHEL 7, og praktisk talt ikke-eksisterende i andre.
• Alle distribusjoner med moderne kjerner har noe støtte for RELRO, med Ubuntu 18.04 som leder an og Debian kommer på andreplass.

Som allerede nevnt, er beregningene i denne tabellen gjennomsnittet for alle versjoner av den binære filen. Hvis du bare ser på de nyeste versjonene av filene, vil tallene være forskjellige (se for eksempel Debian fremgang med PIE-implementering). Dessuten tester de fleste distribusjoner vanligvis bare sikkerheten til noen få funksjoner i binæren ved beregning av statistikk, men vår analyse viser den sanne prosentandelen av funksjoner som er herdet. Derfor, hvis 5 av 50 funksjoner er beskyttet i en binær, vil vi gi den en score på 0,1, som tilsvarer at 10 % av funksjonene styrkes.

Tabell 4. Sikkerhetsegenskaper for de kjørbare filene vist i fig. 3 (implementering av relevante funksjoner som en prosentandel av det totale antallet kjørbare filer)

Tabell 5. Sikkerhetsegenskaper for bibliotekene vist i fig. 3 (implementering av relevante funksjoner i prosent av totalt antall biblioteker)

Så er det fremgang? Det er definitivt: dette kan sees fra statistikken for individuelle distribusjoner (f.eks. Debian), samt fra tabellene ovenfor. Som et eksempel i fig. Figur 6 viser implementeringen av beskyttelsesmekanismer i tre påfølgende distribusjoner av Ubuntu LTS 5 (vi har utelatt stabelkollisjonsbeskyttelsesstatistikk). Vi legger merke til at fra versjon til versjon støtter flere og flere filer stack canaries, og også flere og flere binærfiler sendes med full RELRO-beskyttelse.

Fig. 6

Dessverre har en rekke kjørbare filer i forskjellige distribusjoner fortsatt ingen av de ovennevnte beskyttelsene. Hvis du for eksempel ser på Ubuntu 18.04, vil du legge merke til ngetty-binæren (en getty-erstatning), så vel som mksh- og lksh-skallene, picolisp-tolken, nvidia-cuda-toolkit-pakkene (en populær pakke for GPU-akselererte applikasjoner slik som rammeverk for maskinlæring), og klibc -utils. På samme måte sendes mandos-klient-binæren (et administrativt verktøy som lar deg starte automatisk på nytt maskiner med krypterte filsystemer) samt rsh-redone-client (en reimplementering av rsh og rlogin) uten NX-beskyttelse, selv om de har SUID-rettigheter: (. Dessuten mangler flere suid-binærfiler grunnleggende beskyttelse som stablekanarifugler (for eksempel Xorg.wrap-binærfilen fra Xorg-pakken).

Oppsummering og avsluttende merknader

I denne artikkelen har vi fremhevet flere sikkerhetsfunksjoner i moderne Linux-distribusjoner. Analysen viste at den siste Ubuntu LTS-distribusjonen (18.04) i gjennomsnitt implementerer den sterkeste OS- og applikasjonsnivåbeskyttelsen blant distribusjoner med relativt nye kjerner, som Ubuntu 14.04, 12.04 og Debian 9. De undersøkte distribusjonene CentOS, RHEL og OpenSUSE i vårt sett produserer som standard et tettere sett med pakker, og i de nyeste versjonene (CentOS og RHEL) har de en høyere prosentandel av stabelkollisjonsbeskyttelse sammenlignet med Debian-baserte konkurrenter (Debian og Ubuntu). Sammenligner vi CentOS- og RedHat-versjoner, merker vi store forbedringer i implementeringen av stackkanarifugler og RELRO fra versjon 6 til 7, men i gjennomsnitt har CentOS flere funksjoner implementert enn RHEL. Generelt bør alle distribusjoner være spesielt oppmerksomme på PIE-beskyttelse, som, med unntak av Debian 9 og Ubuntu 18.04, er implementert i mindre enn 10 % av binærfilene i datasettet vårt.

Til slutt bør det bemerkes at selv om vi utførte forskningen manuelt, er det mange sikkerhetsverktøy tilgjengelig (f. Lynis, Tiger, Hubble), som utfører analyser og bidrar til å unngå usikre konfigurasjoner. Dessverre garanterer ikke selv sterk beskyttelse i rimelige konfigurasjoner fravær av utnyttelser. Det er derfor vi er overbevist om at det er viktig å sikre pålitelig overvåking og forebygging av angrep i sanntid, med fokus på utnyttelsesmønstre og forhindre dem.

Kilde: www.habr.com