TL;DR. I denne artikkelen utforskar vi sikringsordningar (hardening schemes) som kjem standard i fem populære Linux-distribusjonar. For kvar av dei har vi brukt standard kjernekonfigurasjon, lasta ned alle pakkar og analysert sikringsskjemer i innbundne binærar. Vi vurderer distribusjonane OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 og 7, samt Ubuntu 14.04, 12.04 og 18.04 LTS.

Resultata bekreftar at sjølv grunnleggjande skjemer som stabelkanariar og posisjonsuavhengig kode, enno ikkje blir brukt av alle. Situasjonen er enda verre for kompilatorar når det kjem til å sikre mot sårbarheiter som stabelkollisjon (stack clash), som fekk oppmerksomheit i januar etter publiseringa av informasjon om sårbarheiter i systemd. Men ikkje alt er så håplaust. I ein betydelig del av binærane er grunnleggjande sikre metodar implementert, og talet på desse auke frå versjon til versjon.

Sjekken viste at det største antallet sikre metodar er implementert i Ubuntu 18.04 på eit OS- og applikasjonsnivå, deretter kjem Debian 9. På den andere sida har OpenSUSE 12.4, CentOS 7 og RHEL 7 også basale sikringsordningar, og beskyttinga mot stabelkollisjon blir utnytta enda breiare med eit mykje tettare sett av pakkar som standard.

Innledning

Det er vanskeleg å sikre høg kvalitet på programvara. Til tross for det enorme antallet av avanserte verktøy for statisk kodeanalyse og dynamisk analyse under kjøring, samt betydelig framgang i utviklinga av kompilatorar og programmeringsspråk, lider moderne programvare framleis av sårbarheiter som stadig blir utnytta av angriparar. Situasjonen er enda meir prekær i økosystem som inkluderer foreldra kode. I slike tilfeller møter vi ikkje berre det evige problemet med å finne potensielle utnyttbare feil, men også er vi avgrensa av strenge rammer for bakoverkompatibilitet som ofte krev at vi må bevare begrensa, og enda verre, sårbar eller feilaktig kode.

Her kjem sikringsmetodane eller forsterkende program (hardening) inn i spelet. Nokre typar feil kan vi ikkje forhindre, men vi kan gjere livet til angriparen meir komplisert og delvis løyse problemet ved å forhindre eller hindre utnyttelse disse feilene. Slik beskyttelse brukes i alle moderne operativsystemer, men metodene varierer sterkt i kompleksitet, effektivitet og ytelse: fra stakkens kanarifugler (stack canaries) og ASLR til fullverdige beskyttelser CFI og ROP. I denne artikkelen vil vi se på hvilke beskyttelsesmetoder som brukes i de mest populære Linux-distribusjonene med standardkonfigurasjon, samt undersøke egenskapene til binærfiler som distribueres gjennom pakkebehandlingssystemene til hver distribusjon.

CVE og sikkerhet

Vi har alle sett artikler med titler som «De mest sårbare applikasjonene i året» eller «De mest sårbare operativsystemene». Vanligvis presenteres det statistikk over det totale antallet registreringer av sårbarheter av typen CVE (Common Vulnerability and Exposures), hentet fra Nasjonal sårbarhetsdatabase (NVD) fra NIST og andre kilder. Senere rangeres disse applikasjonene eller OSene ut fra antall CVE. Dessverre, selv om CVE er svært nyttige for å redusere problemer og informere leverandører og brukere, sier de lite om den faktiske sikkerheten til programvaren.

Som et eksempel kan vi se på det totale antallet CVE 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 CVE at en distribusjon er mer sårbar enn en annen? Svaret er nei. For eksempel, i denne artikkelen vil du se at Debian har implementert strengere beskyttelsesmekanismer sammenlignet med for eksempel OpenSUSE eller RedHat Linux, og allikevel har Debian flere CVE. Men de betyr ikke nødvendigvis svekket sikkerhet: selv tilstedeværelsen av CVE sier ikke noe om en sårbarhet er utnyttbar. Alvorlighetsgradsratinger gir en indikasjon på hvor sannsynlig det er at en sårbarhet blir utnyttet, men til syvende og sist avhenger utnyttbarheten i stor grad av beskyttelsen som er til stede i de berørte systemene, samt ressursene og evnene til angriperne. Videre sier fraværet av CVE-rapporter ikke noe om andre uregistrerte eller ukjente Sikkerhetsproblemer. Forskjellen i CVE kan forklares ikke med kvaliteten på programvaren, men med andre faktorer, inkludert ressursene som er avsatt til testing, eller størrelsen på brukerbasen. I vårt eksempel kan et høyere antall CVE hos Debian bare indikere at Debian leverer flere programvarepakker.

Selvfølgelig gir CVE-systemet nyttig informasjon som muliggjør utvikling av passende beskyttelser. Jo bedre vi forstår årsakene til programfeil, desto enklere er det å identifisere mulige utnyttelsesmetoder og utvikle relevante mekanismer for oppdagelse og respons.Fig. 2 viser kategoriene av sårbarheter for alle distribusjoner de siste fire årene (kilde). Det er umiddelbart synlig at de fleste CVE faller innenfor følgende kategorier: tjenestenekt (DoS), kodegjennomføring, buffer-overløp, minneskade, lekkasje (eksfiltrering) av informasjon og privilegieheving. Selv om mange CVE er registrert flere ganger under forskjellige kategorier, forblir de samme problemene generelt år etter år. I neste del av artikkelen vil vi vurdere bruken av forskjellige beskyttelsesskjemaer for å forhindre utnyttelse av de nevnte sårbarhetene.

Fig. 2

Oppgaver

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

• Hva er sikkerheten til de ulike Linux-distribusjonene? Hvilke beskyttelsesmekanismer eksisterer i kjernen og i applikasjoner i brukerrommet?
• Hvordan har bruken av beskyttelsesmekanismer endret seg over tid for ulike distribusjoner?
• Hva er de gjennomsnittlige avhengighetene av pakker og biblioteker for hver distribusjon?
• Hvilke beskyttelser er implementert for hvert binærprogram?

Valg av distribusjoner

Det viser seg å være vanskelig å finne nøyaktig statistikk om installasjoner av distribusjoner, siden antall nedlastinger i de fleste tilfeller ikke indikerer antall reelle installasjoner. Likevel utgjør Unix-alternativer flertallet av serverbaserte systemer (69,2 % på webservere, ifølge statistikkerne W3techs og andre kilder), og deres andel vokser stadig. Så for vår studie har vi fokusert på distribusjoner tilgjengelig ut av boksen på plattformen Google Cloud. Spesielt valgte vi følgende OS:

Distribusjon/versjon
Kjerne
Bygg

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

Tabell 1

Analyse

Vi vil se på standard kjernekonfigurasjon samt egenskaper ved pakkene tilgjengelig via pakkebehandleren for hver distribusjon fra starten av. Dermed vurderer vi kun pakkene fra standard speil for hver distribusjon, mens vi forsømmer pakker fra ustabile depot (f.eks. speil ‘testing’ i Debian) og tredjeparts pakker (f.eks. Nvidia-pakker fra standard speil). I tillegg vurderer vi ikke brukerspesifikke kernelkompileringer eller konfigurasjoner med økt sikkerhet.

Analyse av kjernekonfigurasjon

Vi har brukt et analyseskjema basert på den frie sjekker kconfig. Vi vurderer sikkerhetsinnstillingene fra starten av for de nevnte distribusjonene og sammenligner dem med listen fra Prosjektet for kjernebeskyttelse (KSPP). For hver konfigurasjonsinnstilling beskriver tabell 2 ønsket konfigurasjon: en avkryssing gjelder for distribusjoner som følger anbefalingene fra KSSP (forklaring av begrepene se her; i kommende artikler vil vi forklare hvordan mange av disse beskyttelsestiltakene oppsto og hvordan man kan hacke systemet i deres fravær).

Generelt har de nye kjernene strengere standardinnstillinger. For eksempel har CentOS 6.10 og RHEL 6.10 med kernel 2.6.32 de fleste kritiske funksjonene implementert i de nye kjernene, slik som SMAP, strenge RWX-tilganger, adresse-randomisering eller beskyttelse av copy2usr. Det er verdt å merke seg at mange av konfigurasjonsalternativene fra tabellen mangler i eldre versjoner av kjernen og ikke er anvendelige i praksis — selv om dette angis i tabellen som mangel på tilstrekkelig beskyttelse. På samme måte, dersom en konfigurasjonsparameter mangler i denne versjonen, men for sikkerhetens skyld må denne parameteren deaktiveres, anses dette som en rimelig konfigurasjon.

En annen viktig faktor ved tolkning av resultater er at noen kjernekonfigurasjoner, som øker angrepsflaten, samtidig kan brukes til sikkerhet. Eksempler inkluderer uprobes og kprobes, kjernekmoduler og BPF/eBPF. Vår anbefaling er å bruke de nevnte mekanismene for å sikre faktisk beskyttelse, da de ikke er trivielle å bruke, og deres utnyttelse forutsetter at ondsinnede aktører allerede har fått fotfeste i systemet. Men hvis disse alternativene er aktivert, bør systemadministratoren aktivt overvåke misbruk.

Ved videre studier av tabell 2 ser vi at moderne kjerner tilbyr flere alternativer for beskyttelse mot utnyttelse av sårbarheter som informasjonslekkasje og stakk/heap-overløp. Vi merker imidlertid at selv de nyeste populære distribusjonene ennå ikke har implementert mer avansert beskyttelse (for eksempel med lappene grsecurity) eller moderne beskyttelse mot angrep med kodegjengivelse (for eksempel, kombinasjon av tilfeldiggjøring med R^X-ordninger for kode). Hva som er enda mer bekymringsfullt, er at selv disse mer avanserte beskyttelsene ikke beskytter mot hele spekteret av angrep. Det er derfor kritisk for systemadministratorer å supplere fornuftige konfigurasjoner med løsninger som tilbyr oppdagelse og forebygging av utnyttelser under kjøring.

Applikasjonsanalyse

Det er ikke overraskende at forskjellige distribusjoner har forskjellige egenskaper som pakkekomprimering, kompilasjonsinnstillinger, biblioteksavhengigheter osv. Det er til og med forskjeller for beslektede distribusjoner og pakker med få avhengigheter (for eksempel coreutils i Ubuntu eller Debian). For å vurdere forskjellene lastet vi ned alle tilgjengelige pakker, ekstraherte innholdet og analyserte binærfilene og avhengighetene. For hver pakke sporet vi andre pakker som den er avhengig av, og for hver binærfil sporet vi avhengighetene. I dette avsnittet gir vi en kort oppsummering av funnene.

Distribusjoner

Totalt har vi lastet opp 361 556 pakker for alle distribusjoner, og trukket ut kun pakker fra standard speil. Vi ignorerte pakker uten ELF-kjørbare filer, som kildekoder, skrifttyper osv. Etter filtrering gjensto 129 569 pakker som til sammen inneholder 584 457 binære filer. Fordelingen av pakker og filer blant distribusjonene er vist i figur 3.

Fig. 3

Det er tydelig at jo mer moderne distribusjonen er, desto flere pakker og binære filer inneholder den, noe som er logisk. Samtidig inkluderer pakker fra Ubuntu og Debian betydelig flere binære filer (både kjørbare og dynamiske moduler og biblioteker) enn CentOS, SUSE og RHEL, noe som potensielt påvirker angrepsflaten til Ubuntu og Debian (det er verdt å merke seg at tallene reflekterer alle binærere av alle versjoner av pakken, noe som betyr at enkelte filer analyseres flere ganger). Dette er spesielt viktig å ta i betraktning når vi ser på avhengighetene mellom pakkene. Dermed kan en sårbarhet i binæren av én pakke påvirke mange deler av økosystemet, ettersom en sårbar biblioteksfil kan påvirke alle binære filer som importerer den. Vi tar som utgangspunkt fordelingen av antall avhengigheter blant pakkene i ulike OS:

Fig. 4

Nesten alle distribusjoner har 60% av pakkene med minst 10 avhengigheter. I tillegg har noen pakker et betydelig høyere antall avhengigheter (over 100). Det samme gjelder for omvendte avhengigheter av pakkene: som ventet brukes flere pakker av mange andre pakker i distribusjonen, så sårbarheter i disse få utvalgte har en høy risiko. Som et eksempel er de 20 pakkene med flest omvendte avhengigheter i SLES, Centos 7, Debian 9 og Ubuntu 18.04 listet opp i tabellen nedenfor (hver celle indikerer pakken og antall omvendte avhengigheter).

Tabell 3

Et interessant faktum. Selv om alle analyserte OS-er er bygget for x86_64-arkitekturen, og for de fleste pakker er arkitekturen definert som x86_64 og x86, inneholder pakkene ofte binære filer for andre arkitekturer, som vist i figur 5.

Fig. 5

I neste del vil vi dykke dypere inn i egenskapene til de analyserte binærfilene.

Statistikk om beskyttelse av binære filer

Som minimum må du lære grunnleggende beskyttelsesalternativer for eksisterende binærfiler. Flere Linux-distribusjoner leveres med skript som utfører slike sjekker. For eksempel har Debian/Ubuntu et slikt skript. Her er et eksempel på hvordan det fungerer:

$ hardening-check $(which docker)
/usr/bin/docker:
 Posisjon Uavhengig Kjørbar: ja
 Stakk beskyttet: ja
 Fortify Source-funksjoner: nei, kun ubeskyttede funksjoner funnet!
 Skrivbeskyttede omplasseringer: ja
 Umiddelbar binding: ja

Skriptet sjekker fem beskyttelsesfunksjoner:

• Posisjon Uavhengig Kjørbar (PIE): indikerer om tekstseksjonen til programmet kan flyttes i minnet for å oppnå tilfeldig plassering, hvis ASLR er aktivert i kjernen.
• Stakk Beskyttet: om stakk-kanarifugler er aktivert for beskyttelse mot stakk-kollisjonsangrep.
• Fortify Source: om usikre funksjoner (for eksempel strcpy) blir erstattet med mer sikre alternativer, og runtime-kall som sjekkes er deres usjekkede alternativer (for eksempel memcpy i stedet for __memcpy_chk).
• Skrivbeskyttede omplasseringer (RELRO): om oppføringer i omplasseringsbordet er merket som 'bare for lesing', hvis de ble aktivert før programutførelsen begynte.
• Umiddelbar binding: tillater omkobler av runtime å resolvere alle omplasseringer før programmet startes (dette er ekvivalent med full RELRO).

Er de nevnte mekanismene tilstrekkelige? Dessverre nei. Det er kjente metoder for å omgå alle nevnte beskyttelser, men jo strengere beskyttelsen er, jo høyere er terskelen for angriperen. For eksempel, metoder for å omgå RELRO er vanskeligere å anvende når PIE og umiddelbar binding er aktiv. Tilsvarende krever full ASLR mer arbeid for å lage en fungerende eksploit. Imidlertid er sofistikerte angripere allerede klare til å møte slike beskyttelser: fraværet av dem vil i praksis akselerere angrepene. Derfor er det ekstremt viktig at disse tiltakene vurderes som et nødvendig minimum.

Vi ønsket å undersøke hvor mange binærfiler i de aktuelle distribusjonene som er beskyttet av disse, samt tre andre metoder:

• Ikke-kjørbar bit (NX) forhindrer kjøring i hvilken som helst region som ikke skal være kjørbar, for eksempel på stakkhopen, osv.
• RPATH/RUNPATH angir kjørebanen som brukes av den dynamiske lasteren for å finne riktige biblioteker. Den første er obligatorisk for any modern system: its absence allows attackers to arbitrarily write payloads into memory and execute them as-is. For the second point, incorrect execution path configurations contribute to the introduction of unreliable code, which can lead to a number of issues (for example, privilege escalation, samt other issues).
• Stack collision protection safeguards against attacks that make the stack overlap with other memory areas (for example, with the heap). Considering recent exploits that take advantage of heap collision vulnerabilities in systemd, we found it appropriate to include this mechanism in our dataset.

So, without further ado, let's move on to the numbers. Tables 4 and 5 provide a summary of the analysis of executable files and libraries from various distributions, respectively.

• As you can see, NX protection is implemented everywhere, with few exceptions. Notably, there is somewhat lower usage in the Ubuntu and Debian distributions compared to CentOS, RHEL, and OpenSUSE.
• Stack canaries are often absent, especially in distributions with older kernels. Some progress is observed in the latest distributions of CentOS, RHEL, Debian, and Ubuntu.
• Except for Debian and Ubuntu 18.04, most distributions have poor PIE support.
• Stack collision protection is weakly implemented in OpenSUSE, CentOS 7, and RHEL 7, and is virtually absent in others.
• All distributions with modern kernels have some support for RELRO, with Ubuntu 18.04 leading, followed by Debian.

As mentioned, the metrics in this table are averages across all versions of the binary file. If we look only at the latest versions of the files, the numbers will differ (for example, see Debian's progress with the implementation of PIE). Moreover, most distributions typically check the security of only a few functions in the binary code when calculating statistics, while our analysis indicates the true percentage of fortified functions. Therefore, if 5 out of 50 functions are secured in a binary, we will give it a score of 0.1, representing 10% fortified functions.

Table 4. Protection characteristics for executable files shown in Figure 3 (implementation of relevant functions as a percentage of the total number of executable files)

Tabell 5. Beskyttelsesegenskaper for bibliotekene vist i figur 3 (implementering av de aktuelle funksjonene i prosent av totalt antall biblioteker)

Er det fremgang? Definitivt: dette kan sees i statistikken for individuelle distribusjoner (for eksempel Debian), samt i tabellene som er nevnt ovenfor. Som et eksempel viser figur 6 implementeringen av beskyttelsesmekanismer i tre påfølgende distribusjoner av Ubuntu LTS 5 (vi har utelatt statistikken for beskyttelse mot stakkoverløp). Vi ser at fra versjon til versjon støtter stadig flere filer stakk-kanyler, og at stadig flere binære filer leveres med full RELRO-beskyttelse.

Figur 6

Dessverre har en rekke kjørbare filer i forskjellige distribusjoner fremdeles ikke noen av beskyttelsene nevnt ovenfor. For eksempel, ved å se på Ubuntu 18.04, kan man observere binæren ngetty (erstatning for getty), samt skallene mksh og lksh, tolken picolisp, pakkene nvidia-cuda-toolkit (en populær pakke for applikasjoner med GPU-akselerasjon, som maskinlæringsrammeverk) og klibc-utils. Tilsvarende leveres binæren mandos-client (et administrasjonsverktøy som automatisk kan starte opp maskiner med krypterte filsystemer), samt rsh-redone-client (en nyimplementering av rsh og rlogin) uten NX-beskyttelse, selv om de har SUID-rettigheter :(. I tillegg er det i flere suid-binære filer ingen grunnleggende beskyttelse, som stakk-kanyler (for eksempel binærfilen Xorg.wrap fra pakken Xorg).

Sammendrag og avsluttende bemerkninger

I denne artikkelen har vi fremhevet flere sikkerhetsegenskaper ved moderne Linux-distribusjoner. Analysen viste at den nyeste Ubuntu LTS-distribusjonen (18.04) i gjennomsnitt har det sterkeste sikkerhetsnivået for operativsystem og applikasjoner blant distribusjoner med relativt nye kjerner, som Ubuntu 14.04, 12.04 og Debian 9. Derimot leverer distribusjonene CentOS, RHEL og OpenSUSE i vårt datasett som standard et tettere pakket sett, og i de nyeste versjonene (CentOS og RHEL) har de en høyere prosentandel av implementering av beskyttelse mot stakkekollisjon, sammenlignet med konkurrentene basert på Debian (Debian og Ubuntu). Når vi sammenligner versjoner av CentOS og RedHat, ser vi store forbedringer i implementeringen av stakkekanari og RELRO fra versjon 6 til 7, men i snitt er det implementert flere funksjoner i CentOS enn i RHEL. Generelt bør alle distribusjoner ha et spesielt fokus på PIE-beskyttelse, som, unntatt Debian 9 og Ubuntu 18.04, er implementert i mindre enn 10 % av de binære filene i vårt datasett.

Til slutt bør det bemerkes: selv om vi har utført forskningen manuelt, finnes det mange sikkerhetsverktøy (for eksempel, Lynis, Tiger, Hubble), som foretar analyser og hjelper med å unngå usikre konfigurasjoner. Dessverre garanterer selv sterk beskyttelse i rimelige konfigurasjoner ikke fravær av exploits. Derfor er vi fast overbevist om at det er avgjørende å sikre pålitelige overvåking og beskyttelse mot angrep i sanntid, med fokus på utnyttelsesmodeller og forhindre dem.

Kilde: habr.com