TL; DR. I den här artikeln utforskar vi de härdningsscheman som fungerar direkt på fem populära Linux-distributioner. För varje tog vi standardkärnkonfigurationen, laddade alla paket och analyserade säkerhetsscheman i de bifogade binärfilerna. Distributionerna som övervägs är OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 och 7, samt Ubuntu 14.04, 12.04 och 18.04 LTS.
Resultaten bekräftar att inte ens grundläggande system som att stapla kanariefåglar och positionsoberoende kod ännu inte har antagits av alla. Situationen är ännu värre för kompilatorer när det gäller att skydda mot sårbarheter som stackclash, som kom i rampljuset i januari efter publicering . Men allt är inte så hopplöst. Ett betydande antal binärer implementerar grundläggande skyddsmetoder, och deras antal växer från version till version.
Granskningen visade att det största antalet skyddsmetoder är implementerade i Ubuntu 18.04 på OS- och applikationsnivåer, följt av Debian 9. Å andra sidan implementerar OpenSUSE 12.4, CentOS 7 och RHEL 7 också grundläggande skyddsscheman och stackkollisionsskydd används ännu mer allmänt med en mycket tätare uppsättning standardpaket.
Inledning
Det är svårt att säkerställa programvara av hög kvalitet. Trots ett stort antal avancerade verktyg för statisk kodanalys och dynamisk runtime-analys, samt betydande framsteg i utvecklingen av kompilatorer och programmeringsspråk, lider modern programvara fortfarande av sårbarheter som ständigt utnyttjas av angripare. Situationen är ännu värre i ekosystem som inkluderar äldre kod. I sådana fall står vi inte bara inför det eviga problemet att hitta möjliga exploateringsbara fel, utan vi är också begränsade av strikta bakåtkompatibilitetsramverk, som ofta kräver att vi bevarar begränsad, eller ännu värre, sårbar eller buggig kod.
Det är här metoder för att skydda eller härda program kommer in i bilden. Vi kan inte förhindra vissa typer av fel, men vi kan göra angriparens liv svårare och delvis lösa problemet genom att förhindra eller förhindra utnyttjande dessa fel. Sådant skydd används i alla moderna operativsystem, men metoderna skiljer sig mycket i komplexitet, effektivitet och prestanda: från stackkanariefåglar och till fullt skydd и . I den här artikeln kommer vi att titta på vilka skyddsmetoder som används i de mest populära Linux-distributionerna i standardkonfigurationen, och även undersöka egenskaperna för de binärer som distribueras genom pakethanteringssystemen för varje distribution.
CVE och säkerhet
Vi har alla sett artiklar med titlar som "Årets mest sårbara applikationer" eller "De mest sårbara operativsystemen." Vanligtvis tillhandahåller de statistik över det totala antalet poster om sårbarheter som , tagen från från och andra källor. Därefter rangordnas dessa applikationer eller OS efter antalet CVE. Tyvärr, även om CVE:er är mycket användbara för att spåra problem och informera leverantörer och användare, säger de lite om den faktiska säkerheten för programvaran.
Som ett exempel, betrakta det totala antalet CVE:er under de senaste fyra åren för Linux-kärnan och de fem mest populära serverdistributionerna, nämligen Ubuntu, Debian, Red Hat Enterprise Linux och OpenSUSE.
FIG. 1
Vad säger den här grafen oss? Betyder ett högre antal CVE:er att en distribution är mer sårbar än en annan? Inget svar. Till exempel, i den här artikeln kommer du att se att Debian har starkare säkerhetsmekanismer jämfört med exempelvis OpenSUSE eller RedHat Linux, och ändå har Debian fler CVE:er. Men de betyder inte nödvändigtvis försvagad säkerhet: även närvaron av en CVE indikerar inte om en sårbarhet är utnyttjas. Allvarlighetspoäng ger en indikation på hur förmodligen exploatering av en sårbarhet, men i slutändan beror exploateringsbarheten i hög grad på skyddet som finns i de drabbade systemen och angriparnas resurser och kapacitet. Dessutom säger frånvaron av CVE-rapporter ingenting om andra oregistrerad eller okänd sårbarheter. Skillnaden i CVE kan bero på andra faktorer än mjukvarans kvalitet, inklusive de resurser som tilldelats för testning eller storleken på användarbasen. I vårt exempel kan Debians högre antal CVE helt enkelt indikera att Debian skickar fler programvarupaket.
Naturligtvis ger CVE-systemet användbar information som gör att du kan skapa lämpliga skydd. Ju bättre vi förstår orsakerna till programfel, desto lättare är det att identifiera möjliga metoder för exploatering och utveckla lämpliga mekanismer upptäckt och svar. I fig. 2 visar kategorierna av sårbarheter för alla distributioner under de senaste fyra åren (). Det är omedelbart klart att de flesta CVE:er faller inom följande kategorier: denial of service (DoS), kodexekvering, spill, minneskorruption, informationsläckage (exfiltrering) och privilegieskalering. Även om många CVE räknas flera gånger i olika kategorier, kvarstår i allmänhet samma problem år efter år. I nästa del av artikeln kommer vi att utvärdera användningen av olika skyddssystem för att förhindra utnyttjande av dessa sårbarheter.
FIG. 2
uppgifter
I den här artikeln tänker vi svara på följande frågor:
- Vad är säkerheten för olika Linux-distributioner? Vilka skyddsmekanismer finns i kärnan och användarutrymmesapplikationerna?
- Hur har antagandet av säkerhetsmekanismer förändrats över tid över distributioner?
- Vilka är de genomsnittliga beroenden för paket och bibliotek för varje distribution?
- Vilka skydd implementeras för varje binär?
Urval av distributioner
Det visar sig att det är svårt att hitta korrekt statistik över distributionsinstallationer, eftersom antalet nedladdningar i de flesta fall inte anger antalet faktiska installationer. Unix-varianter utgör dock majoriteten av serversystemen (på webbservrar 69,2 %, med W3techs och andra källor), och deras andel växer ständigt. För vår forskning fokuserade vi därför på distributioner tillgängliga direkt på plattformen . I synnerhet valde vi följande OS:
Distribution/version
kärna
Bygga
OpenSUSE 12.4
4.12.14-95.3-standard
#1 SMP ons 5 dec 06:00:48 UTC 2018 (63a8d29)
Debian 9 (stretch)
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 Tis 15 Jan 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
Tabell 1
Analys
Låt oss studera standardkärnkonfigurationen, såväl som egenskaperna för paket som är tillgängliga via pakethanteraren för varje distribution direkt från lådan. Därför tar vi bara hänsyn till paket från varje distributions standardspeglar, och ignorerar paket från instabila förråd (som Debians 'testande' speglar) och tredjepartspaket (som Nvidia-paket från standardspeglar). Dessutom överväger vi inte anpassade kärnkompilationer eller säkerhetshärdade konfigurationer.
Kärnkonfigurationsanalys
Vi tillämpade ett analysskript baserat på . Låt oss titta på skyddsparametrarna för de namngivna distributionerna och jämföra dem med listan från (KSPP). För varje konfigurationsalternativ beskriver tabell 2 den önskade inställningen: kryssrutan är för distributioner som följer KSSP-rekommendationerna (se följande för en förklaring av termer). ; I framtida artiklar kommer vi att förklara hur många av dessa säkerhetsmetoder kom till och hur man hackar ett system i deras frånvaro).
I allmänhet har de nya kärnorna strängare inställningar direkt. Till exempel saknar CentOS 6.10 och RHEL 6.10 på 2.6.32-kärnan de flesta av de kritiska funktionerna implementerade i nyare kärnor som t.ex. , strikta RWX-behörigheter, adressrandomisering eller copy2usr-skydd. Det bör noteras att många av konfigurationsalternativen i tabellen inte är tillgängliga i äldre versioner av kärnan och inte är tillämpliga i verkligheten - detta indikeras fortfarande i tabellen som en brist på korrekt skydd. På samma sätt, om ett konfigurationsalternativ inte finns i en given version, och säkerheten kräver att alternativet är inaktiverat, anses detta vara en rimlig konfiguration.
En annan punkt att tänka på när man tolkar resultaten: vissa kärnkonfigurationer som ökar attackytan kan också användas för säkerhet. Sådana exempel inkluderar uprober och kprobes, kärnmoduler och BPF/eBPF. Vår rekommendation är att använda ovanstående mekanismer för att ge verkligt skydd, eftersom de är icke-triviala att använda och deras utnyttjande förutsätter att illvilliga aktörer redan har etablerat sig i systemet. Men om dessa alternativ är aktiverade måste systemadministratören aktivt övervaka för missbruk.
Om vi tittar vidare på posterna i tabell 2 ser vi att moderna kärnor ger flera alternativ för att skydda mot exploatering av sårbarheter som informationsläckage och stack/heap overflows. Vi märker dock att även de senaste populära distributionerna ännu inte har implementerat mer komplext skydd (till exempel med patchar ) eller modernt skydd mot kodåteranvändningsattacker (t.ex. ). För att göra saken värre skyddar inte ens dessa mer avancerade försvar mot alla attacker. Därför är det avgörande för systemadministratörer att komplettera smarta konfigurationer med lösningar som erbjuder upptäckt och förebyggande av runtime-exploatering.
Tillämpningsanalys
Inte överraskande har olika distributioner olika paketegenskaper, kompileringsalternativ, biblioteksberoenden etc. Skillnader finns även för distributioner och paket med ett litet antal beroenden (till exempel coreutils på Ubuntu eller Debian). För att utvärdera skillnaderna laddade vi ner alla tillgängliga paket, extraherade deras innehåll och analyserade binärer och beroenden. För varje paket höll vi reda på de andra paketen det beror på, och för varje binär spårade vi dess beroenden. I det här avsnittet sammanfattar vi kort slutsatserna.
Distributioner
Totalt laddade vi ner 361 556 paket för alla distributioner, och extraherade endast paket från standardspeglar. Vi ignorerade paket utan ELF-körbara filer, såsom källor, typsnitt, etc. Efter filtrering återstod 129 569 paket, innehållande totalt 584 457 binärer. Fördelningen av paket och filer över distributioner visas i fig. 3.
FIG. 3
Du kanske märker att ju modernare distributionen är, desto fler paket och binärer innehåller den, vilket är logiskt. Ubuntu- och Debian-paketen innehåller dock många fler binärfiler (både körbara filer och dynamiska moduler och bibliotek) än CentOS, SUSE och RHEL, vilket potentiellt påverkar attackytan på Ubuntu och Debian (det bör noteras att siffrorna återspeglar alla binärer av alla versioner paket, det vill säga vissa filer analyseras flera gånger). Detta är särskilt viktigt när du tänker på beroenden mellan paket. Således kan en sårbarhet i ett binärt paket påverka många delar av ekosystemet, precis som ett sårbart bibliotek kan påverka alla binära filer som importerar det. Som utgångspunkt, låt oss titta på fördelningen av antalet beroenden mellan paket i olika operativsystem:
FIG. 4
I nästan alla distributioner har 60 % av paketen minst 10 beroenden. Dessutom har vissa paket ett betydligt större antal beroenden (fler än 100). Detsamma gäller för omvända paketberoenden: som förväntat används ett fåtal paket av många andra paket i distributionen, så sårbarheter i de få utvalda är hög risk. Som ett exempel listar följande tabell de 20 paketen med det maximala antalet omvända beroenden i SLES, Centos 7, Debian 9 och Ubuntu 18.04 (varje cell anger paketet och antalet omvända beroenden).
Tabell 3
Intressant fakta. Även om alla analyserade operativsystem är byggda för x86_64-arkitekturen, och de flesta paket har arkitekturen definierad som x86_64 och x86, innehåller paket ofta binärer för andra arkitekturer, som visas i figur 5. XNUMX.
FIG. 5
I nästa avsnitt kommer vi att fördjupa oss i egenskaperna hos de analyserade binärerna.
Binär filskyddsstatistik
Som ett absolut minimum måste du utforska en grundläggande uppsättning säkerhetsalternativ för dina befintliga binärer. Flera Linux-distributioner kommer med skript som utför sådana kontroller. Till exempel har Debian/Ubuntu ett sådant skript. Här är ett exempel på hans arbete:
$ 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: yesManuset kontrollerar fem :
- Position Independent Executable (PIE): Indikerar om textdelen av ett program kan flyttas i minnet för att uppnå randomisering om ASLR är aktiverat i kärnan.
- Stack Protected: Huruvida stack kanariefåglar är aktiverade för att skydda mot stackkollisionsattacker.
- Fortify Source: om osäkra funktioner (till exempel strcpy) ersätts med sina säkrare motsvarigheter och anrop som kontrolleras vid körning ersätts med deras okontrollerade motsvarigheter (till exempel memcpy istället för __memcpy_chk).
- Skrivskyddade omlokaliseringar (RELRO): Huruvida omlokaliseringstabellposter är markerade som skrivskyddade om de utlöses innan exekveringen börjar.
- Omedelbar bindning: Huruvida runtime-linkern tillåter alla drag innan programkörningen börjar (detta motsvarar en fullständig RELRO).
Är ovanstående mekanismer tillräckliga? Tyvärr inte. Det finns kända sätt att kringgå alla ovanstående försvar, men ju tuffare försvar, desto högre ribban för angriparen. Till exempel, svårare att tillämpa om PIE och omedelbar bindning är i kraft. På samma sätt kräver full ASLR ytterligare arbete för att skapa en fungerande exploit. Men sofistikerade angripare är redan beredda att möta sådana skydd: deras frånvaro kommer i huvudsak att påskynda hacket. Det är därför väsentligt att dessa åtgärder anses nödvändiga minimum.
Vi ville studera hur många binära filer i distributionerna i fråga som skyddas av dessa och tre andra metoder:
- Okörbar bit () förhindrar exekvering i alla regioner som inte borde vara körbara, såsom stackhögen, etc.
- anger exekveringsvägen som används av den dynamiska laddaren för att hitta matchande bibliotek. Den första är obligatoriskt för alla moderna system: dess frånvaro tillåter angripare att godtyckligt skriva in nyttolasten i minnet och köra den som den är. För det andra hjälper felaktiga körvägskonfigurationer till att introducera opålitlig kod som kan leda till ett antal problem (t.ex. Och ).
- Stackkollisionsskydd ger skydd mot attacker som gör att stacken överlappar andra minnesområden (som högen). Med tanke på den senaste tidens missbruk , ansåg vi att det var lämpligt att inkludera denna mekanism i vår datauppsättning.
Så, utan vidare, låt oss gå ner till siffrorna. Tabell 4 och 5 innehåller en sammanfattning av analysen av körbara filer respektive bibliotek av olika distributioner.
- Som du kan se är NX-skydd implementerat överallt, med sällsynta undantag. I synnerhet kan man notera dess något lägre användning i Ubuntu och Debian-distributioner jämfört med CentOS, RHEL och OpenSUSE.
- Stackkanariefåglar saknas på många ställen, särskilt i distributioner med äldre kärnor. Vissa framsteg kan ses i de senaste distributionerna av Centos, RHEL, Debian och Ubuntu.
- Med undantag för Debian och Ubuntu 18.04 har de flesta distributioner dåligt PIE-stöd.
- Stackkollisionsskydd är svagt i OpenSUSE, Centos 7 och RHEL 7, och praktiskt taget obefintligt i andra.
- Alla distributioner med moderna kärnor har visst stöd för RELRO, där Ubuntu 18.04 leder vägen och Debian kommer på andra plats.
Som redan nämnts är måtten i denna tabell genomsnittet för alla versioner av den binära filen. Om du bara tittar på de senaste versionerna av filerna kommer siffrorna att vara olika (se till exempel ). Dessutom testar de flesta distributioner vanligtvis bara säkerheten för ett fåtal funktioner i binären vid beräkning av statistik, men vår analys visar den sanna andelen funktioner som är härdade. Därför, om 5 av 50 funktioner är skyddade i en binär så ger vi den poängen 0,1, vilket motsvarar att 10 % av funktionerna förstärks.
Tabell 4. Säkerhetsegenskaper för de körbara filerna som visas i Fig. 3 (implementering av relevanta funktioner i procent av det totala antalet körbara filer)
Tabell 5. Säkerhetsegenskaper för biblioteken som visas i fig. 3 (implementering av relevanta funktioner i procent av det totala antalet bibliotek)
Så finns det framsteg? Det finns definitivt: detta kan ses från statistiken för individuella distributioner (till exempel, ), samt från tabellerna ovan. Som ett exempel i fig. Figur 6 visar implementeringen av skyddsmekanismer i tre successiva distributioner av Ubuntu LTS 5 (vi har utelämnat stackkollisionsskyddsstatistik). Vi märker att från version till version stöder fler och fler filer stack canarys, och även fler och fler binärer skickas med fullt RELRO-skydd.
FIG. 6
Tyvärr har ett antal körbara filer i olika distributioner fortfarande inget av ovanstående skydd. Om du till exempel tittar på Ubuntu 18.04 kommer du att märka binären ngetty (en getty-ersättning), såväl som mksh- och lksh-skalen, picolisp-tolken, paketen nvidia-cuda-toolkit (ett populärt paket för GPU-accelererade applikationer såsom ramverk för maskininlärning) och klibc -utils. Likaså skickas binären mandos-klient (ett administrativt verktyg som låter dig starta om maskiner med krypterade filsystem) samt rsh-redone-client (en omimplementering av rsh och rlogin) utan NX-skydd, även om de har SUID-rättigheter: (. Dessutom saknar flera suid-binärer grundläggande skydd som stackkanariefåglar (till exempel Xorg.wrap-binären från Xorg-paketet).
Sammanfattning och avslutande kommentarer
I den här artikeln har vi lyft fram flera säkerhetsfunktioner hos moderna Linux-distributioner. Analysen visade att den senaste Ubuntu LTS-distributionen (18.04) implementerar i genomsnitt det starkaste OS- och programnivåskyddet bland distributioner med relativt nya kärnor, som Ubuntu 14.04, 12.04 och Debian 9. De undersökta distributionerna CentOS, RHEL och OpenSUSE i vår uppsättning producerar som standard en tätare uppsättning paket, och i de senaste versionerna (CentOS och RHEL) har de en högre procentandel av stackkollisionsskydd jämfört med Debian-baserade konkurrenter (Debian och Ubuntu). Jämför vi CentOS- och RedHat-versioner märker vi stora förbättringar i implementeringen av stackcanariefåglar och RELRO från version 6 till 7, men i genomsnitt har CentOS fler funktioner implementerade än RHEL. I allmänhet bör alla distributioner ägna särskild uppmärksamhet åt PIE-skydd, som, med undantag för Debian 9 och Ubuntu 18.04, är implementerat i mindre än 10 % av binärfilerna i vår datauppsättning.
Slutligen bör det noteras att även om vi utförde forskningen manuellt, finns det många säkerhetsverktyg tillgängliga (t.ex. , , ), som utför analys och hjälper till att undvika osäkra konfigurationer. Tyvärr garanterar inte ens starkt skydd i rimliga konfigurationer frånvaron av utnyttjande. Det är därför vi är övertygade om att det är viktigt att säkerställa , med fokus på exploateringsmönster och förebyggande av dem.
Källa: will.com