TL;DR. I denna artikel utforskar vi hårdningsscheman (hardening schemes) som fungerar från start i fem populära Linux-distributioner. För varje har vi tagit standard kärnkonfigurationen, laddat ner alla paket och analyserat skyddsscheman i de inbäddade binära filerna. Distributioner som behandlas ä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 även grundläggande scheman, såsom stack Canary och positionoberoende kod, fortfarande inte används av alla. Situationen är ännu värre för kompilatorer när det kommer till skydd mot sårbarheter som stack clash, som kom i fokus i januari efter publiceringen av information om sårbarheter i systemd. Men allt är inte hopplöst. En betydande del av binära filer implementerar grundläggande skyddsåtgärder, och antalet ökar från version till version.

Kontrollen visade att flest skyddsåtgärder har implementerats i Ubuntu 18.04 på OS- och applikationsnivå, följt av Debian 9. Å andra sidan är grundläggande skyddsscheman också implementerade i OpenSUSE 12.4, CentOS 7 och RHEL 7, medan skydd mot stack clash tillämpas ännu mer utbrett med en mycket tätare uppsättning standardpaket.

Introduktion

Det är svårt att säkerställa hög kvalitet på programvara. Trots det stora antalet avancerade verktyg för statisk kodanalys och dynamisk analys under körning, samt betydande framsteg inom kompilatorer och programmeringsspråk, lider modern mjukvara fortfarande av sårbarheter som ständigt utnyttjas av angripare. Situationen är ännu svårare i ekosystem som inkluderar gammal kod. I sådana fall står vi inte bara inför det eviga problemet med att hitta potentiellt exploaterbara fel, utan vi är också begränsade av strikta krav på bakåtkompatibilitet som ofta tvingar oss att behålla begränsad, och ännu värre, sårbar eller buggig kod.

Här kommer skyddsmetoder eller hårdning (hardening) in i bilden. Vissa typer av fel kan vi inte förhindra, men vi kan göra livet svårare för angriparen och delvis lösa problemet genom att förhindra eller hindra. utnyttjande dessa fel. Detta skydd används i alla moderna operativsystem, men metoderna skiljer sig mycket åt när det gäller komplexitet, effektivitet och prestanda: från stackcanaries och ASLR till fullvärdigt skydd CFI och ROP. I denna artikel kommer vi att titta på vilka skyddsåtgärder som används i de mest populära Linux-distributionerna i standardkonfigurationen, samt undersöka egenskaperna hos de binära filer som distribueras via pakethanteringssystemen för varje distribution.

CVE och säkerhet

Vi har alla sett artiklar med titlar som "De mest sårbara programvarorna under året" eller "De mest sårbara operativsystemen". Vanligtvis presenteras statistik över det totala antalet poster för sårbarheter av typen CVE (Common Vulnerability and Exposures), erhållna från Nationella sårbarhetsdatabasen (NVD) från NIST och andra källor. Dessa program eller operativsystem rangordnas senare efter antalet CVE. Tyvärr, även om CVE är mycket användbara för att spåra problem och informera leverantörer och användare, säger de lite om den verkliga säkerheten hos programvaran.

Som ett exempel, låt oss betrakta det totala antalet CVE de senaste fyra åren för Linux-kärnan och fem av de mest populära serverdistributionerna, nämligen Ubuntu, Debian, Red Hat Enterprise Linux och OpenSUSE.

Fig. 1

Vad säger denna graf oss? Betyder ett högre antal CVE att en distribution är mer sårbar än en annan? Svaret är nej. Till exempel kommer du i denna artikel att se att Debian har mer strikta skyddsmekanismer jämfört med OpenSUSE eller RedHat Linux, och ändå har Debian fler CVE. Men det betyder inte nödvändigtvis en försvagad säkerhet: att ha CVE betyder inte om en sårbarhet är utnyttjad. Allvarlighetsgrader ger en uppfattning om hur sannolikt det är att utnyttja en sårbarhet, men i slutändan beror utnyttjande i stor utsträckning på det skydd som finns i de drabbade systemen samt på resurser och möjligheter för angriparna. Dessutom säger avsaknaden av CVE-rapporter ingenting om andra oregistrerande eller okända Sårbarheter. Skillnaden i CVE kan förklaras av inte bara mjukvarukvaliteten utan också av andra faktorer, inklusive resurser som avsatts för testning eller storleken på användarbasen. I vårt exempel kan det större antalet CVE i Debian helt enkelt indikera att Debian tillhandahåller fler programvarupaket.

Självklart ger CVE-systemet användbar information som gör det möjligt att skapa adekvata skydd. Ju bättre vi förstår orsakerna till programvarufel, desto enklare blir det att identifiera potentiella utnyttjanden och utveckla motsvarande mekanismer. för upptäckte och respons. På figur 2 visas kategorier av sårbarheter för alla distributioner under de senaste fyra åren (ClickHouse-Ninja/Proton). Det framgår tydligt att de flesta CVE faller inom följande kategorier: DoS (Denial of Service), kodexekvering, buffertöverskridning, minneskorruption, läckage (utexfiltrering) av information och privilegieförhöjning. Även om många CVE redovisas flera gånger i olika kategorier kvarstår generellt samma problem år efter år. I nästa del av artikeln kommer vi att utvärdera användningen av olika skyddsscheman för att förhindra exploatering av de angivna sårbarheterna.

Figur 2

Uppgifter

I den här artikeln avser vi att svara på följande frågor:

• Hur säker är de olika Linux-distributionerna? Vilka skyddsmekanismer finns i kärnan och i program som körs av användaren?
• Hur har acceptansen av skyddsmekanismer förändrats över tid för olika distributioner?
• Vilka är de genomsnittliga beroendena för paket och bibliotek för varje distribution?
• Vilka skydd implementeras för varje binärfil?

Val av distributioner

Det visar sig vara svårt att hitta exakt statistik för installationer av distributioner, eftersom antal nedladdningar i de flesta fall inte anger antalet verkliga installationer. Ändå utgör Unix-alternativ majoriteten av serversystem (69,2 % på webbservrar enligt W3techs och andra källor), och deras andel växer konstant. Därför fokuserade vi i vår forskning på distributioner som är tillgängliga direkt från plattformen. statistik I synnerhet valde vi följande operativsystem: Google CloudDistribution/version

Bygg
Kärna
OpenSUSE 12.4

4.12.14-95.3-default
Debian 9 (stretch)
#1 SMP Wed Dec 5 06:00:48 UTC 2018 (63a8d29)

4.9.0-8-amd64
CentOS 6.10
#1 SMP Debian 4.9.130-2 (2018-10-27)

2.6.32-754.10.1.el6.x86_64
3.10.0-957.5.1.el7.x86_64
#1 SMP Tue Jan 15 17:07:28 UTC 2019

CentOS 7
Red Hat Enterprise Linux Server 6.10 (Santiago)
#1 SMP Fri Feb 1 14:54:57 UTC 2019

2.6.32-754.9.1.el6.x86_64
Red Hat Enterprise Linux Server 7.6 (Maipo)
#1 SMP Wed Nov 21 15:08:21 EST 2018

3.10.0-957.1.3.el7.x86_64
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

Analys

Vi kommer att granska standardkonfigurationen av kärnan samt egenskaperna hos paketen som finns tillgängliga genom paketförvaltaren för varje distribution från början. Därmed beaktar vi endast paket från standardservrarna för varje distribution, och ignorerar paket från instabila repon (t.ex. 'testing' servrar i Debian) och tredjepartspaket (t.ex. Nvidia-paket från standardservrar). Dessutom tar vi inte hänsyn till användarkompilerade kärnor eller konfigurationer med ökad säkerhet.

Analys av kärnkonfiguration

Vi har tillämpat en analyskript baserat på den fria kconfig-kontrollen. Vi granskar skyddskonfigurationerna som finns från början i de nämnda distributionerna och jämför dem med listan från Kernel Self Protection Project (KSPP). För varje konfigurationsparameter beskriver Tabell 2 önskad inställning: ett kryss finns för distributioner som uppfyller KSSP:s rekommendationer (förklaringar till termerna se. här; i framtida artiklar kommer vi att berätta hur många av dessa skyddsmetoder uppstod och hur man kan hacka systemet i deras frånvaro).

Överlag har nya kärnor striktare inställningar från början. Till exempel har CentOS 6.10 och RHEL 6.10 med kärnan 2.6.32 de flesta kritiska funktioner som implementerats i nya kärnor, såsom SMAP, strikta RWX-behörigheter, slumpmässig adressering eller skydd copy2usr. Det bör noteras att många av konfigurationsalternativen i tabellen saknas i äldre versioner av kärnan och inte är tillämpliga i praktiken – i tabellen anges detta fortfarande som en brist på adekvat skydd. På liknande sätt, om en konfigurationsparameter saknas i denna version, och för säkerheten måste denna parameter inaktiveras, anses detta vara en rimlig konfiguration.

Ytterligare en punkt vid tolkning av resultaten: vissa kärnkonfigurationer som ökar attackytan kan samtidigt användas för säkerhet. Sådana exempel inkluderar uprobes och kprobes, kärnmoduler samt BPF/eBPF. Vår rekommendation är att använda ovan nämnda mekanismer för att säkerställa verkligt skydd, eftersom de är svåra att använda och utnyttjandet förutsätter att skadliga aktörer redan har fått fäste i systemet. Men om dessa alternativ är aktiverade bör systemadministratören aktivt övervaka missbruk.

När vi undersöker tabell 2 närmare ser vi att moderna kärnor erbjuder flera alternativ för att skydda sig mot utnyttjande av sårbarheter som informationsläckage och stack-/heapöversvämning. Men vi noterar att även de senaste populära distributionerna ännu inte har implementerat mer avancerat skydd (till exempel med patchar grsecurity) eller modern skydd mot återanvändningsattacker (till exempel, kombinera randomisering med R^X-liknande scheman för kod). Vad som är ännu värre är att även dessa mer avancerade skydd inte skyddar mot hela spektrumet av attacker. Därför är det oerhört viktigt för systemadministratörer att komplettera rimliga konfigurationer med lösningar som erbjuder upptäckning och förebyggande av exploateringar under körning.

Applikationsanalys

Det är inte förvånande att olika distributioner har olika paketegenskaper, kompileringsalternativ, bibliotekberoenden och så vidare. Skillnader finns även för relaterade distributioner och paket med få beroenden (till exempel coreutils i Ubuntu eller Debian). För att utvärdera skillnaderna laddade vi ner alla tillgängliga paket, extraherade deras innehåll och analyserade binärfiler och beroenden. För varje paket spårade vi andra paket som det är beroende av, och för varje binärfil spårade vi dess beroenden. I detta avsnitt sammanfattar vi våra slutsatser.

Distributioner

Totalt har vi laddat ner 361 556 paket för alla distributioner, med endast paket hämtade från standardservrar. Vi ignorerade paket utan ELF-exekverbara filer, såsom källkoder, typsnitt, etc. Efter filtrering återstod 129 569 paket som innehöll totalt 584 457 binära filer. Fördelningen av paket och filer per distribution visas i figur 3.

Fig. 3

Det kan märkas att ju modernare distributionen är, desto fler paket och binära filer innehåller den, vilket är logiskt. Paketen från Ubuntu och Debian innehåller mycket fler binära filer (både exekverbara och dynamiska moduler och bibliotek) än CentOS, SUSE och RHEL, vilket potentiellt påverkar angreppsyta för Ubuntu och Debian (det bör noteras att siffrorna speglar alla binärer från alla versioner av paketet, dvs vissa filer analyseras flera gånger). Detta är särskilt viktigt med tanke på beroenden mellan paket. En sårbarhet i en binär av ett paket kan påverka många delar av ekosystemet, precis som en sårbarhet i ett bibliotek kan påverka alla binära filer som importerar det. Som referens ser vi på fördelningen av antalet beroenden per paket i olika operativsystem:

Fig. 4

I nästan alla distributioner har 60% av paketen minst 10 beroenden. Dessutom har vissa paket betydligt fler beroenden (över 100). Detsamma gäller för omvända beroenden av paket: som förväntat används flera paket av många andra paket i distributionen, så sårbarheter i dessa få utvalda har en hög risk. Som exempel listas i nästa tabell 20 paket med flest omvända beroenden i SLES, Centos 7, Debian 9 och Ubuntu 18.04 (i varje cell anges paketet och antalet omvända beroenden).

Tabell 3

Intressant nog. Även om alla analyserade operativsystem är byggda för arkitekturen x86_64, och de flesta paket har arkitekturen definierad som x86_64 och x86, innehåller paket ofta binära filer för andra arkitekturer, som visas i figur 5.

Fig. 5

I nästa avsnitt dyker vi djupare in i egenskaperna hos de analyserade binärerna.

Statistik över skydd av binära filer

Som ett absolut minimum bör du studera en grundläggande uppsättning skyddsalternativ för de binära filer som finns. Flera Linux-distributioner levereras med skript som utför sådana kontroller. Till exempel finns det ett sådant skript i Debian/Ubuntu. Här är ett exempel på dess arbete:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: ja
 Stack protected: ja
 Fortify Source functions: nej, endast oskyddade funktioner hittades!
 Read-only relocations: ja
 Immediate binding: ja

Skriptet kontrollerar fem skyddsfunktioner:

• Position Independent Executable (PIE): anger om textavsnittet i programmet kan flyttas i minnet för att åstadkomma randomisering, om ASLR är aktiverat i kärnan.
• Stack Protected: är stackkanarier aktiverade för att skydda mot stackkollisioner.
• Fortify Source: ersätts osäkra funktioner (t.ex. strcpy) med deras säkrare motsvarigheter, medan de som kontrolleras i realtid anropas med sina oskyddade motsvarigheter (t.ex. memcpy istället för __memcpy_chk).
• Read-only relocations (RELRO): är posterna i omfördelningstabellen märkta som "endast läsning" om de aktiveras innan programmet körs.
• Immediate binding (omedelbar bindning): tillåter länkaren att hantera alla förflyttningar före programmets start (detta är ekvivalent med full RELRO).

Är de ovan nämnda mekanismerna tillräckliga? Tyvärr, nej. Det finns kända sätt att kringgå alla ovan nämnda skydd, men ju striktare skyddet är, desto högre blir tröskeln för angriparen. Till exempel, metoder för att kringgå RELRO är svårare att tillämpa om PIE och omedelbar bindning är aktiverade. På liknande sätt kräver full ASLR mer arbete för att skapa en fungerande exploateringskod. Men avancerade angripare är redan beredda att bemöta sådana skydd: deras frånvaro påskyndar i princip hackningen. Därför är det extremt viktigt att dessa åtgärder betraktas som nödvändiga. minimum.

Vi ville studera hur många binära filer i de granskade distributionerna som är skyddade av dessa samt tre ytterligare metoder:

• Icke-exekverbart bit (NX) förhindrar utförande i vilken region som helst som inte ska vara exekverbar, till exempel på stacken och så vidare.
• RPATH/RUNPATH anger sökvägen som används av dynamiska laddaren för att hitta motsvarande bibliotek. Den första är obligatorisk för vilket modernt system som helst: dess frånvaro tillåter angripare att skriva in nyttolasten i minnet på ett godtyckligt sätt och köra den som den är. För det andra hjälper felaktiga konfigurationer av körvägen till att införa osäker kod, vilket kan leda till en rad problem (till exempel, privilegiehöjning, samt andra problem).
• Skydd mot stackkollisioner skyddar mot attacker som tvingar stacken att överlappa med andra minnesområden (som heapen). Givet de senaste exploateringarna som utnyttjar säkerhetsluckorna med heapkollisioner i systemd, ansåg vi det lämpligt att inkludera denna mekanism i vår datamängd.

Så, utan vidare omsvep, går vi vidare till siffrorna. Tabellerna 4 och 5 innehåller en sammanställning av analysen av körbara filer och bibliotek för olika distributioner, respektive.

• Som kan noteras, är NX-skydd implementerat överallt, med några få undantag. Speciellt kan man notera en något lägre användning av detta i distributionerna Ubuntu och Debian jämfört med CentOS, RHEL och OpenSUSE.
• Stackcanarier saknas på många ställen, särskilt i distributioner med gamla kärnor. Viss framsteg har observerats i de senaste distributionerna av CentOS, RHEL, Debian och Ubuntu.
• Förutom Debian och Ubuntu 18.04, är stödet för PIE dåligt i de flesta distributioner.
• Skydd mot stackkollisioner är svagt implementerat i OpenSUSE, CentOS 7 och RHEL 7 och praktiskt taget frånvarande i de andra.
• Alla distributioner med moderna kärnor har viss support för RELRO, där Ubuntu 18.04 ligger i topp, följt av Debian.

Som nämnts tidigare representerar mätvärdena i denna tabell medelvärdet för alla versioner av den binära filen. Om man ser på bara de senaste versionerna av filerna, kommer siffrorna att bli annorlunda (till exempel se. framstegen i Debian med införandet av PIE). Dessutom, kontrollerar de flesta distributioner vanligtvis skyddet för endast några funktioner i den binära koden när man räknar statistiken, medan vår analys visar den sanna procentandelen av förstärkta funktioner. Så om 5 av 50 funktioner i binären är skyddade, visar vi det med betyget 0,1 vilket motsvarar 10% förstärkta funktioner.

Tabell 4. Skyddskarakteristika för körbara filer, visade i figur 3 (implementeringen av motsvarande funktioner i procent av det totala antalet körbara filer)

Tabell 5. Skyddskarakteristik för biblioteken som visas i figur 3 (implementering av relevanta funktioner i procent av det totala antalet bibliotek)

Finns det framsteg? Definitivt: det är tydligt från statistiken för olika distributioner (till exempel, Debian), samt från de ovanstående tabellerna. Som ett exempel visas i figur 6 implementeringen av skyddsmekanismer i tre på varandra följande Ubuntu LTS-distributioner 5 (vi har utelämnat statistiken för skydd mot stackkollaps). Vi noterar att fler och fler filer från version till version stöder stackkanariefunktionen, och dessutom levereras allt fler binära filer med full RELRO-skydd.

Figur 6

Tyvärr har en rad körbara filer i olika distributioner fortfarande inga av de ovan nämnda skydden. Till exempel, om man tittar på Ubuntu 18.04, kan man se det binära programmet ngetty (ersättning för getty), samt skal mksh och lksh, tolken picolisp, paketen nvidia-cuda-toolkit (ett populärt paket för GPU-accelererade applikationer, som maskininlärningsramverk) och klibc-utils. På samma sätt levereras det binära programmet mandos-client (ett administrativt verktyg som möjliggör automatisk omstart av maskiner med krypterade filsystem), samt rsh-redone-client (återimplementering av rsh och rlogin) utan NX-skydd, trots att de har SUID-rättigheter :(. Dessutom saknar flera suid-binärfiler grundläggande skydd, såsom stackkanariefunktion (till exempel det binära programmet Xorg.wrap från paketet Xorg).

Sammanfattning och avslutande anmärkningar

I den här artikeln har vi lyft fram flera säkerhetsegenskaper hos moderna Linux-distributioner. Analysen visade att den senaste versionen av Ubuntu LTS (18.04) i genomsnitt har det starkaste skyddet på OS- och applikationsnivå bland distributioner med relativt nya kärnor, såsom Ubuntu 14.04, 12.04 och Debian 9. De granskade distributionerna CentOS, RHEL och OpenSUSE har emellertid i vår datamängd gynnsammare paketinstallationer som standard, och i de senaste versionerna (CentOS och RHEL) har de en högre procentandel av skydd mot stack-kollisioner jämfört med Debian-baserade konkurrenter (Debian och Ubuntu). När vi jämför versioner av CentOS och RedHat märker vi stora förbättringar i implementeringen av stack-canaries och RELRO mellan version 6 och 7, men i genomsnitt har CentOS fler funktioner implementerade än RHEL. Generellt sett bör alla distributioner ägna särskild uppmärksamhet åt skyddet av PIE, som, med undantag för Debian 9 och Ubuntu 18.04, är implementerat i mindre än 10 % av de binära filerna i vår datamängd.

Slutligen bör det noteras: även om vi genomfört forskningen manuellt finns det många säkerhetsverktyg (t.ex. Lynis, Tiger, Hubble), som utför analyser och hjälper till att undvika osäkra konfigurationer. Tyvärr garanterar även starka skydd i rimliga konfigurationer inte frånvaro av exploateringar. Det är därför vi är starkt övertygade om att det är livsviktigt att tillhandahålla trovärdig övervakning och skydd mot attacker i realtid, med fokus på exploateringsmönster och att förebygga dem.

Källa: habr.com