TL; DR. In dit artikel onderzoeken we de verhardingsschema's die kant-en-klaar werken op vijf populaire Linux-distributies. Voor elk pakket hebben we de standaard kernelconfiguratie genomen, alle pakketten geladen en de beveiligingsschema's in de bijgevoegde binaire bestanden geanalyseerd. De beschouwde distributies zijn OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 en 7, evenals Ubuntu 14.04, 12.04 en 18.04 LTS.

De resultaten bevestigen dat zelfs basisschema’s zoals het stapelen van kanaries en positie-onafhankelijke code nog niet door iedereen worden overgenomen. De situatie is nog erger voor compilers als het gaat om bescherming tegen kwetsbaarheden zoals stack clash, die in januari na publicatie in de schijnwerpers kwam te staan. informatie over systeemkwetsbaarheden. Maar niet alles is zo hopeloos. Een aanzienlijk aantal binaire bestanden implementeert basisbeschermingsmethoden, en hun aantal groeit van versie tot versie.

Uit de review bleek dat het grootste aantal beschermingsmethoden is geïmplementeerd in Ubuntu 18.04 op besturingssysteem- en applicatieniveau, gevolgd door Debian 9. Aan de andere kant implementeren OpenSUSE 12.4, CentOS 7 en RHEL 7 ook basisbeschermingsschema's en bescherming tegen stapelbotsingen. wordt nog breder gebruikt met een veel compactere set standaardpakketten.

Introductie

Het is moeilijk om software van hoge kwaliteit te garanderen. Ondanks het enorme aantal geavanceerde tools voor statische code-analyse en dynamische runtime-analyse, evenals de aanzienlijke vooruitgang in de ontwikkeling van compilers en programmeertalen, kampt moderne software nog steeds met kwetsbaarheden die voortdurend door aanvallers worden uitgebuit. De situatie is zelfs nog erger in ecosystemen die verouderde code bevatten. In dergelijke gevallen worden we niet alleen geconfronteerd met het eeuwige probleem van het vinden van mogelijke exploiteerbare fouten, maar worden we ook beperkt door strikte achterwaartse compatibiliteitsframeworks, die ons vaak verplichten om beperkte, of erger nog, kwetsbare code of code met fouten te behouden.

Dit is waar methoden voor het beschermen of verharden van programma's een rol gaan spelen. Sommige soorten fouten kunnen we niet voorkomen, maar we kunnen het leven van de aanvaller moeilijker maken en het probleem gedeeltelijk oplossen door het voorkomen of voorkomen exploitatie deze fouten. Dergelijke bescherming wordt in alle moderne besturingssystemen gebruikt, maar de methoden verschillen enorm in complexiteit, efficiëntie en prestaties: van stapelkanaries en ASLR tot volledige bescherming CFI и ROP. In dit artikel zullen we bekijken welke beveiligingsmethoden worden gebruikt in de meest populaire Linux-distributies in de standaardconfiguratie, en ook de eigenschappen onderzoeken van de binaire bestanden die worden gedistribueerd via de pakketbeheersystemen van elke distributie.

CVE en beveiliging

We hebben allemaal artikelen gezien met titels als 'De meest kwetsbare applicaties van het jaar' of 'De meest kwetsbare besturingssystemen'. Meestal bieden ze statistieken over het totale aantal records over kwetsbaarheden, zoals CVE (gemeenschappelijke kwetsbaarheid en blootstelling), verkregen van Nationale Kwetsbaarheidsdatabase (NVD) van NIST en andere bronnen. Vervolgens worden deze applicaties of besturingssystemen gerangschikt op basis van het aantal CVE’s. Hoewel CVE's erg nuttig zijn voor het opsporen van problemen en het informeren van leveranciers en gebruikers, zeggen ze helaas weinig over de daadwerkelijke veiligheid van de software.

Neem als voorbeeld het totale aantal CVE’s van de afgelopen vier jaar voor de Linux-kernel en de vijf populairste serverdistributies, namelijk Ubuntu, Debian, Red Hat Enterprise Linux en OpenSUSE.

Fig. 1

Wat vertelt deze grafiek ons? Betekent een groter aantal CVE’s dat de ene distributie kwetsbaarder is dan de andere? Geen antwoord. In dit artikel zul je bijvoorbeeld zien dat Debian sterkere beveiligingsmechanismen heeft vergeleken met bijvoorbeeld OpenSUSE of RedHat Linux, en toch heeft Debian meer CVE's. Ze betekenen echter niet noodzakelijkerwijs een verzwakte veiligheid: zelfs de aanwezigheid van een CVE geeft niet aan of er sprake is van een kwetsbaarheid uitgebuit. Ernstscores geven een indicatie van hoe waarschijnlijk misbruik van een kwetsbaarheid, maar uiteindelijk hangt de exploiteerbaarheid sterk af van de bescherming die aanwezig is in de getroffen systemen en van de middelen en mogelijkheden van de aanvallers. Bovendien zegt het ontbreken van CVE-rapporten niets over anderen niet geregistreerd of onbekend kwetsbaarheden. Het verschil in CVE kan te wijten zijn aan andere factoren dan de kwaliteit van de software, waaronder de middelen die zijn toegewezen aan het testen of de omvang van het gebruikersbestand. In ons voorbeeld kan het hogere aantal CVE's van Debian eenvoudigweg erop wijzen dat Debian meer softwarepakketten levert.

Uiteraard biedt het CVE-systeem nuttige informatie waarmee u passende beveiligingen kunt creëren. Hoe beter we de redenen voor het mislukken van programma's begrijpen, hoe gemakkelijker het is om mogelijke exploitatiemethoden te identificeren en passende mechanismen te ontwikkelen detectie en reactie. In afb. Figuur 2 toont de kwetsbaarheidscategorieën voor alle distributies van de afgelopen vier jaar (bron). Het is meteen duidelijk dat de meeste CVE’s in de volgende categorieën vallen: denial of service (DoS), code-uitvoering, overflow, geheugencorruptie, informatielekken (exfiltratie) en escalatie van privileges. Hoewel veel CVE's meerdere keren in verschillende categorieën worden geteld, blijven dezelfde problemen jaar na jaar bestaan. In het volgende deel van het artikel zullen we het gebruik van verschillende beveiligingsprogramma's evalueren om misbruik van deze kwetsbaarheden te voorkomen.

Fig. 2

taken

In dit artikel willen we de volgende vragen beantwoorden:

• Wat is de beveiliging van verschillende Linux-distributies? Welke beschermingsmechanismen bestaan ​​er in de kernel- en gebruikersruimtetoepassingen?
• Hoe is de acceptatie van beveiligingsmechanismen in de loop van de tijd binnen distributies veranderd?
• Wat zijn de gemiddelde afhankelijkheden van pakketten en bibliotheken voor elke distributie?
• Welke beveiligingen zijn geïmplementeerd voor elk binair bestand?

Selectie van distributies

Het blijkt dat het moeilijk is om nauwkeurige statistieken over distributie-installaties te vinden, omdat in de meeste gevallen het aantal downloads niet het aantal daadwerkelijke installaties aangeeft. Unix-varianten vormen echter het merendeel van de serversystemen (op webservers 69,2%, door statistiek W3techs en andere bronnen), en hun aandeel groeit voortdurend. Daarom hebben we ons voor ons onderzoek gericht op distributies die out-of-the-box beschikbaar zijn op het platform Google Cloud. In het bijzonder hebben we het volgende besturingssysteem geselecteerd:

Distributie/versie
kern
Bouwen

OpenSUSE 12.4
4.12.14-95.3-standaard
#1 SMP wo 5 december 06:00:48 UTC 2018 (63a8d29)

Debian 9 (uitrekken)
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 di 15 januari 17:07:28 UTC 2019

7 CentOS
3.10.0-957.5.1.el7.x86_64
#1 SMP vrijdag 1 februari 14:54:57 UTC 2019

Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP wo 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 do 15 november 17:36:42 UTC 2018

Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-generiek

#166~14.04.1-Ubuntu SMP za 17 november 01:52:43 UTC 20…

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

Ubuntu 18.04 (Bionische Bever)
4.15.0–1026-gcp
#27-Ubuntu SMP do 6 december 18:27:01 UTC 2018

Tabel 1

Analyse

Laten we de standaard kernelconfiguratie bestuderen, evenals de eigenschappen van pakketten die beschikbaar zijn via de pakketbeheerder van elke kant-en-klare distributie. We houden dus alleen rekening met pakketten van de standaardspiegelservers van elke distributie, waarbij we pakketten uit onstabiele repository's (zoals de 'testing'-spiegelservers van Debian) en pakketten van derden (zoals Nvidia-pakketten van standaardspiegelservers) negeren. Bovendien houden we geen rekening met aangepaste kernelcompilaties of beveiligingsconfiguraties.

Kernelconfiguratieanalyse

We hebben een analysescript toegepast op basis van gratis kconfig-controle. Laten we eens kijken naar de kant-en-klare beveiligingsparameters van de genoemde distributies en deze vergelijken met de lijst uit Kernzelfverdedigingsproject (KSPP). Voor elke configuratieoptie beschrijft Tabel 2 de gewenste instelling: het selectievakje is voor distributies die voldoen aan de KSSP-aanbevelingen (zie hieronder voor een uitleg van de termen). hier; In toekomstige artikelen zullen we uitleggen hoeveel van deze beveiligingsmethoden zijn ontstaan ​​en hoe je een systeem kunt hacken als ze er niet zijn).

Over het algemeen hebben de nieuwe kernels standaard strengere instellingen. CentOS 6.10 en RHEL 6.10 op de 2.6.32-kernel missen bijvoorbeeld de meeste kritieke functies die zijn geïmplementeerd in nieuwere kernels, zoals SMAP, strikte RWX-machtigingen, adresrandomisatie of copy2usr-beveiliging. Opgemerkt moet worden dat veel van de configuratie-opties in de tabel niet beschikbaar zijn in oudere versies van de kernel en in werkelijkheid niet van toepassing zijn - dit wordt in de tabel nog steeds aangegeven als een gebrek aan goede bescherming. Ook als een configuratieoptie niet aanwezig is in een bepaalde versie en de beveiliging vereist dat die optie wordt uitgeschakeld, wordt dit als een redelijke configuratie beschouwd.

Nog een punt waarmee rekening moet worden gehouden bij het interpreteren van de resultaten: sommige kernelconfiguraties die het aanvalsoppervlak vergroten, kunnen ook voor beveiliging worden gebruikt. Dergelijke voorbeelden omvatten uprobes en kprobes, kernelmodules en BPF/eBPF. Onze aanbeveling is om de bovenstaande mechanismen te gebruiken om echte bescherming te bieden, omdat ze niet triviaal zijn om te gebruiken en de exploitatie ervan ervan uitgaat dat kwaadwillende actoren al voet aan de grond hebben gekregen in het systeem. Maar als deze opties zijn ingeschakeld, moet de systeembeheerder actief controleren op misbruik.

Als we verder kijken naar de gegevens in Tabel 2, zien we dat moderne kernels verschillende opties bieden voor bescherming tegen misbruik van kwetsbaarheden zoals het lekken van informatie en stack/heap overflows. We merken echter dat zelfs de meest recente populaire distributies nog geen complexere bescherming hebben geïmplementeerd (bijvoorbeeld met patches grote veiligheid) of moderne bescherming tegen aanvallen op hergebruik van code (bijv. combinatie van randomisatie met schema's zoals R^X voor code). Tot overmaat van ramp bieden zelfs deze meer geavanceerde verdedigingsmechanismen geen bescherming tegen het volledige scala aan aanvallen. Daarom is het van cruciaal belang dat systeembeheerders slimme configuraties aanvullen met oplossingen die runtime-exploitdetectie en -preventie bieden.

Applicatie Analyse

Het is niet verrassend dat verschillende distributies verschillende pakketkenmerken, compilatieopties, bibliotheekafhankelijkheden, enz. hebben. Er bestaan ​​zelfs verschillen voor verwant distributies en pakketten met een klein aantal afhankelijkheden (bijvoorbeeld coreutils op Ubuntu of Debian). Om de verschillen te evalueren, hebben we alle beschikbare pakketten gedownload, de inhoud eruit gehaald en de binaire bestanden en afhankelijkheden geanalyseerd. Voor elk pakket hebben we de andere pakketten bijgehouden waarvan het afhankelijk is, en voor elk binair bestand hebben we de afhankelijkheden ervan bijgehouden. In deze paragraaf vatten we de conclusies kort samen.

Uitkeringen

In totaal hebben we 361 pakketten gedownload voor alle distributies, waarbij we alleen pakketten uit de standaard mirrors hebben geëxtraheerd. We negeerden pakketten zonder ELF-uitvoerbare bestanden, zoals bronnen, lettertypen, enz. Na het filteren bleven er 556 pakketten over, met een totaal van 129 binaire bestanden. De distributie van pakketten en bestanden over verschillende distributies wordt getoond in Fig. 569.

Fig. 3

Het zal je misschien opvallen dat hoe moderner de distributie is, hoe meer pakketten en binaire bestanden deze bevat, wat logisch is. Ubuntu- en Debian-pakketten bevatten echter veel meer binaire bestanden (zowel uitvoerbare bestanden als dynamische modules en bibliotheken) dan CentOS, SUSE en RHEL, wat mogelijk het aanvalsoppervlak van Ubuntu en Debian beïnvloedt (opgemerkt moet worden dat de cijfers alle binaire bestanden van alle versies weerspiegelen pakket, dat wil zeggen dat sommige bestanden meerdere keren worden geanalyseerd). Dit is vooral belangrijk als u rekening houdt met de afhankelijkheden tussen pakketten. Een kwetsbaarheid in een enkel binair pakket kan dus vele delen van het ecosysteem beïnvloeden, net zoals een kwetsbare bibliotheek alle binaire bestanden kan beïnvloeden die het importeren. Laten we als uitgangspunt eens kijken naar de verdeling van het aantal afhankelijkheden tussen pakketten in verschillende besturingssystemen:

Fig. 4

In bijna alle distributies heeft 60% van de pakketten minstens 10 afhankelijkheden. Bovendien hebben sommige pakketten een aanzienlijk groter aantal afhankelijkheden (meer dan 100). Hetzelfde geldt voor omgekeerde pakketafhankelijkheden: zoals verwacht worden een paar pakketten door veel andere pakketten in de distributie gebruikt, dus kwetsbaarheden in die selecte groep vormen een hoog risico. Als voorbeeld vermeldt de volgende tabel de 20 pakketten met het maximale aantal omgekeerde afhankelijkheden in SLES, Centos 7, Debian 9 en Ubuntu 18.04 (elke cel geeft het pakket en het aantal omgekeerde afhankelijkheden aan).

Tabel 3

Interessant feit. Hoewel alle geanalyseerde besturingssystemen zijn gebouwd voor de x86_64-architectuur, en de meeste pakketten de architectuur hebben gedefinieerd als x86_64 en x86, bevatten pakketten vaak binaire bestanden voor andere architecturen, zoals weergegeven in Figuur 5. XNUMX.

Fig. 5

In de volgende sectie zullen we dieper ingaan op de kenmerken van de geanalyseerde binaire bestanden.

Statistieken over binaire bestandsbeveiliging

Op het absolute minimum moet u een basisset beveiligingsopties voor uw bestaande binaire bestanden verkennen. Verschillende Linux-distributies worden geleverd met scripts die dergelijke controles uitvoeren. Debian/Ubuntu heeft bijvoorbeeld zo'n script. Hier is een voorbeeld van zijn werk:

$ 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

Het script controleert er vijf beschermingsfuncties:

• Position Independent Executable (PIE): Geeft aan of de tekstsectie van een programma in het geheugen kan worden verplaatst om randomisatie te bereiken als ASLR is ingeschakeld in de kernel.
• Stack Protected: Of stapelkanaries zijn ingeschakeld om te beschermen tegen stapelbotsingsaanvallen.
• Bron versterken: of onveilige functies (bijvoorbeeld strcpy) worden vervangen door hun veiligere tegenhangers, en of oproepen die tijdens runtime worden gecontroleerd, worden vervangen door hun niet-gecontroleerde tegenhangers (bijvoorbeeld memcpy in plaats van __memcpy_chk).
• Alleen-lezen verplaatsingen (RELRO): Of verplaatsingstabelitems als alleen-lezen worden gemarkeerd als ze worden geactiveerd voordat de uitvoering begint.
• Onmiddellijke binding: of de runtime-linker alle bewegingen toestaat voordat de uitvoering van het programma begint (dit komt overeen met een volledige RELRO).

Zijn bovenstaande mechanismen voldoende? Helaas niet. Er zijn bekende manieren om alle bovenstaande verdedigingen te omzeilen, maar hoe sterker de verdediging, hoe hoger de lat voor de aanvaller. Bijvoorbeeld, RELRO-bypass-methoden moeilijker toe te passen als PIE en onmiddellijke binding van kracht zijn. Op dezelfde manier vereist volledige ASLR extra werk om een ​​werkende exploit te creëren. Geavanceerde aanvallers zijn echter al voorbereid op dergelijke bescherming: hun afwezigheid zal de hack in wezen versnellen. Het is daarom essentieel dat deze maatregelen noodzakelijk worden geacht minimum.

We wilden onderzoeken hoeveel binaire bestanden in de betreffende distributies door deze en drie andere methoden worden beschermd:

• Niet-uitvoerbaar bit (NX) voorkomt uitvoering in elke regio die niet uitvoerbaar zou moeten zijn, zoals de stapelheap, enz.
• RPATH/RUNPATH geeft het uitvoeringspad aan dat door de dynamische lader wordt gebruikt om overeenkomende bibliotheken te vinden. De eerste is verplicht voor elk modern systeem: door de afwezigheid ervan kunnen aanvallers de payload willekeurig in het geheugen schrijven en deze uitvoeren zoals hij is. Wat het tweede betreft, helpen onjuiste uitvoeringspadconfiguraties bij het introduceren van onbetrouwbare code die tot een aantal problemen kan leiden (bijv. privilege escalatieEn andere problemen).
• Beveiliging tegen stapelbotsingen biedt bescherming tegen aanvallen die ervoor zorgen dat de stapel andere geheugengebieden (zoals de heap) overlapt. Gezien recente misbruiken systemd heap-kwetsbaarhedenvonden we het passend om dit mechanisme in onze dataset op te nemen.

Laten we dus, zonder verder oponthoud, naar de cijfers gaan. Tabellen 4 en 5 bevatten een samenvatting van de analyse van respectievelijk uitvoerbare bestanden en bibliotheken van verschillende distributies.

• Zoals u kunt zien, wordt NX-bescherming overal geïmplementeerd, met zeldzame uitzonderingen. In het bijzonder kan men het iets lagere gebruik ervan opmerken in Ubuntu- en Debian-distributies vergeleken met CentOS, RHEL en OpenSUSE.
• Stack-canaries ontbreken op veel plaatsen, vooral in distributies met oudere kernels. Er is enige vooruitgang te zien in de nieuwste distributies van Centos, RHEL, Debian en Ubuntu.
• Met uitzondering van Debian en Ubuntu 18.04 hebben de meeste distributies slechte PIE-ondersteuning.
• Bescherming tegen stapelbotsingen is zwak in OpenSUSE, Centos 7 en RHEL 7, en vrijwel onbestaande in andere.
• Alle distributies met moderne kernels hebben enige ondersteuning voor RELRO, waarbij Ubuntu 18.04 voorop loopt en Debian op de tweede plaats komt.

Zoals reeds vermeld zijn de statistieken in deze tabel het gemiddelde voor alle versies van het binaire bestand. Als u alleen naar de nieuwste versies van bestanden kijkt, zullen de cijfers anders zijn (zie bijvoorbeeld Debian boekt vooruitgang met de PIE-implementatie). Bovendien testen de meeste distributies doorgaans alleen de veiligheid van een paar functies in het binaire bestand bij het berekenen van statistieken, maar onze analyse toont het werkelijke percentage functies dat is beveiligd. Als 5 van de 50 functies in een binair bestand worden beschermd, geven we het daarom een ​​score van 0,1, wat overeenkomt met 10% van de functies die worden versterkt.

Tabel 4. Beveiligingskenmerken voor de uitvoerbare bestanden getoond in Fig. 3 (implementatie van relevante functies als percentage van het totale aantal uitvoerbare bestanden)

Tabel 5. Beveiligingskenmerken voor de bibliotheken getoond in Fig. 3 (implementatie van relevante functies als percentage van het totaal aantal bibliotheken)

Is er dus vooruitgang? Dat is er zeker: dit blijkt uit de statistieken van individuele uitkeringen (bijvoorbeeld Debian), evenals uit de bovenstaande tabellen. Als voorbeeld in afb. Figuur 6 toont de implementatie van beveiligingsmechanismen in drie opeenvolgende distributies van Ubuntu LTS 5 (we hebben statistieken over de bescherming tegen stapelbotsingen weggelaten). We merken dat van versie tot versie steeds meer bestanden stack-canaries ondersteunen, en dat steeds meer binaries worden geleverd met volledige RELRO-bescherming.

Fig. 6

Helaas beschikken een aantal uitvoerbare bestanden in verschillende distributies nog steeds niet over de bovenstaande beveiligingen. Als je bijvoorbeeld naar Ubuntu 18.04 kijkt, zul je het binaire bestand ngetty (een vervanging van Getty) opmerken, evenals de mksh- en lksh-shells, de picolisp-interpreter, de nvidia-cuda-toolkit-pakketten (een populair pakket voor GPU-versnelde applicaties zoals machine learning-frameworks) en klibc -utils. Op dezelfde manier worden de mandos-client binary (een administratieve tool waarmee je machines met gecodeerde bestandssystemen automatisch opnieuw kunt opstarten) en rsh-redone-client (een herimplementatie van rsh en rlogin) geleverd zonder NX-bescherming, hoewel ze SUID-rechten hebben: (. Ook missen verschillende suid-binaire bestanden basisbescherming, zoals stapelkanaries (bijvoorbeeld het binaire bestand Xorg.wrap uit het Xorg-pakket).

Samenvatting en slotopmerkingen

In dit artikel hebben we verschillende beveiligingsfuncties van moderne Linux-distributies belicht. Uit de analyse bleek dat de nieuwste Ubuntu LTS-distributie (18.04) gemiddeld de sterkste bescherming op besturingssysteem- en applicatieniveau implementeert onder distributies met relatief nieuwe kernels, zoals Ubuntu 14.04, 12.04 en Debian 9. De onderzochte distributies CentOS, RHEL en OpenSUSE in onze set produceert standaard een dichtere set pakketten, en in de nieuwste versies (CentOS en RHEL) hebben ze een hoger percentage stack-botsingsbescherming vergeleken met op Debian gebaseerde concurrenten (Debian en Ubuntu). Als we de CentOS- en RedHat-versies vergelijken, zien we grote verbeteringen in de implementatie van stackcanaries en RELRO van versie 6 tot 7, maar gemiddeld heeft CentOS meer functies geïmplementeerd dan RHEL. Over het algemeen moeten alle distributies speciale aandacht besteden aan PIE-bescherming, die, met uitzondering van Debian 9 en Ubuntu 18.04, is geïmplementeerd in minder dan 10% van de binaire bestanden in onze dataset.

Ten slotte moet worden opgemerkt dat, hoewel we het onderzoek handmatig hebben uitgevoerd, er veel beveiligingshulpmiddelen beschikbaar zijn (bijv. Lynis, Tijger, Hubble), die analyses uitvoeren en onveilige configuraties helpen voorkomen. Helaas garandeert zelfs sterke bescherming in redelijke configuraties niet de afwezigheid van exploits. Daarom zijn wij ervan overtuigd dat het essentieel is om dit te garanderen betrouwbare monitoring en preventie van aanvallen in realtime, waarbij de nadruk ligt op uitbuitingspatronen en het voorkomen ervan.

Bron: www.habr.com