TL; DR. In hierdie artikel ondersoek ons die verhardingskemas wat uit die boks werk op vyf gewilde Linux-verspreidings. Vir elkeen het ons die verstekkernkonfigurasie geneem, al die pakkette gelaai en die sekuriteitskemas in die aangehegte binaries ontleed. Die verspreidings wat oorweeg word, is OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 en 7, sowel as Ubuntu 14.04, 12.04 en 18.04 LTS.
Die resultate bevestig dat selfs basiese skemas soos stapelkanaries en posisie-onafhanklike kode nog nie deur almal aanvaar word nie. Die situasie is selfs erger vir samestellers wanneer dit kom by die beskerming teen kwesbaarhede soos stapelbotsing, wat in Januarie ná publikasie in die kollig gekom het. . Maar nie alles is so hopeloos nie. 'n Beduidende aantal binaries implementeer basiese beskermingsmetodes, en hul aantal groei van weergawe tot weergawe.
Die hersiening het getoon dat die grootste aantal beskermingsmetodes in Ubuntu 18.04 op die bedryfstelsel- en toepassingsvlakke geïmplementeer word, gevolg deur Debian 9. Aan die ander kant implementeer OpenSUSE 12.4, CentOS 7 en RHEL 7 ook basiese beskermingskemas, en stapelbotsingsbeskerming word selfs meer wyd gebruik met 'n baie digter stel verstekpakkette.
Inleiding
Dit is moeilik om sagteware van hoë gehalte te verseker. Ten spyte van die groot aantal gevorderde gereedskap vir statiese kode-analise en dinamiese looptyd-analise, sowel as aansienlike vordering in die ontwikkeling van samestellers en programmeertale, ly moderne sagteware steeds aan kwesbaarhede wat voortdurend deur aanvallers uitgebuit word. Die situasie is selfs erger in ekosisteme wat nalatenskapkode insluit. In sulke gevalle word ons nie net gekonfronteer met die ewige probleem om moontlike uitbuitbare foute te vind nie, maar ons word ook beperk deur streng terugwaartse versoenbaarheidsraamwerke, wat dikwels vereis dat ons beperkte, of selfs erger, kwesbare of foutiewe kode bewaar.
Dit is waar metodes van beskerming of verharding van programme ter sprake kom. Ons kan nie sekere soorte foute voorkom nie, maar ons kan die aanvaller se lewe moeiliker maak en die probleem gedeeltelik oplos deur te voorkom of te voorkom uitbuiting hierdie foute. Sulke beskerming word in alle moderne bedryfstelsels gebruik, maar die metodes verskil baie in kompleksiteit, doeltreffendheid en werkverrigting: van stapelkanaries en tot volle beskerming и . In hierdie artikel sal ons kyk na watter beskermingsmetodes gebruik word in die gewildste Linux-verspreidings in die verstekkonfigurasie, en ook die eienskappe van die binaries ondersoek wat deur die pakketbestuurstelsels van elke verspreiding versprei word.
CVE en sekuriteit
Ons het almal artikels gesien met titels soos "Die mees kwesbare toepassings van die jaar" of "Die mees kwesbare bedryfstelsels." Gewoonlik verskaf hulle statistieke oor die totale aantal rekords oor kwesbaarhede soos , verkry van van en ander bronne. Vervolgens word hierdie toepassings of bedryfstelsels volgens die aantal CVE's gerangskik. Ongelukkig, hoewel CVE's baie nuttig is om kwessies op te spoor en verskaffers en gebruikers in te lig, sê hulle min oor die werklike sekuriteit van die sagteware.
As 'n voorbeeld, oorweeg die totale aantal CVE's oor die afgelope vier jaar vir die Linux-kern en die vyf gewildste bedienerverspreidings, naamlik Ubuntu, Debian, Red Hat Enterprise Linux en OpenSUSE.
Fig. 1
Wat sê hierdie grafiek vir ons? Beteken 'n groter aantal CVE's dat een verspreiding meer kwesbaar is as 'n ander? Geen antwoord. Byvoorbeeld, in hierdie artikel sal jy sien dat Debian sterker sekuriteitsmeganismes het in vergelyking met byvoorbeeld OpenSUSE of RedHat Linux, en tog het Debian meer CVE's. Dit beteken egter nie noodwendig verswakte sekuriteit nie: selfs die teenwoordigheid van 'n CVE dui nie aan of 'n kwesbaarheid is uitgebuit. Erns tellings gee 'n aanduiding van hoe waarskynlik uitbuiting van 'n kwesbaarheid, maar uiteindelik hang uitbuitbaarheid grootliks af van die beskerming wat in die geaffekteerde stelsels teenwoordig is en die hulpbronne en vermoëns van die aanvallers. Boonop sê die afwesigheid van CVE-verslae niks van ander nie ongeregistreer of onbekend kwesbaarhede. Die verskil in CVE kan te wyte wees aan ander faktore as sagtewarekwaliteit, insluitend die hulpbronne wat aan toetsing toegewys is of die grootte van die gebruikersbasis. In ons voorbeeld kan Debian se groter aantal CVE's eenvoudig aandui dat Debian meer sagtewarepakkette stuur.
Natuurlik verskaf die CVE-stelsel nuttige inligting wat jou toelaat om toepaslike beskerming te skep. Hoe beter ons die redes vir programmislukking verstaan, hoe makliker is dit om moontlike metodes van uitbuiting te identifiseer en toepaslike meganismes te ontwikkel opsporing en reaksie. In Fig. 2 toon die kategorieë van kwesbaarhede vir alle verspreidings oor die afgelope vier jaar (). Dit is onmiddellik duidelik dat die meeste CVE's in die volgende kategorieë val: ontkenning van diens (DoS), kode-uitvoering, oorloop, geheue-korrupsie, inligtinglekkasie (eksfiltrasie) en voorregte-eskalasie. Alhoewel baie CVE's verskeie kere in verskillende kategorieë getel word, bly dieselfde kwessies oor die algemeen jaar na jaar voort. In die volgende deel van die artikel sal ons die gebruik van verskeie beskermingskemas evalueer om die uitbuiting van hierdie kwesbaarhede te voorkom.
Fig. 2
take
In hierdie artikel beoog ons om die volgende vrae te beantwoord:
- Wat is die sekuriteit van verskillende Linux-verspreidings? Watter beskermingsmeganismes bestaan in die kern- en gebruikersruimtetoepassings?
- Hoe het die aanvaarding van sekuriteitsmeganismes oor tyd oor verspreidings verander?
- Wat is die gemiddelde afhanklikhede van pakkette en biblioteke vir elke verspreiding?
- Watter beskerming word vir elke binêre geïmplementeer?
Seleksie van verspreidings
Dit blyk dat dit moeilik is om akkurate statistieke oor verspreidingsinstallasies te vind, aangesien die aantal aflaaie in die meeste gevalle nie die aantal werklike installasies aandui nie. Unix-variante maak egter die meerderheid van bedienerstelsels uit (op webbedieners 69,2%, deur W3techs en ander bronne), en hul aandeel groei voortdurend. Dus, vir ons navorsing het ons gefokus op verspreidings wat buite die boks op die platform beskikbaar is . Ons het veral die volgende bedryfstelsel gekies:
Verspreiding/weergawe
kern
Bou
OpenSUSE 12.4
4.12.14-95.3-verstek
#1 SMP Wo 5 Des 06:00:48 UTC 2018 (63a8d29)
Debian 9 (rek)
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 Di 15 Januarie 17:07:28 UTC 2019
CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP Vr 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 Wo 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 Do 15 Nov 17:36:42 UTC 2018
Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-generies
#166~14.04.1-Ubuntu SMP Sat 17 Nov 01:52:43 UTC 20...
Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP Vr 7 Des 09:59:47 UTC 2018
Ubuntu 18.04 (Bioniese Bever)
4.15.0–1026-gcp
#27-Ubuntu SMP Do 6 Des 18:27:01 UTC 2018
Tabel 1
Analise
Kom ons bestudeer die verstek kernkonfigurasie, sowel as die eienskappe van pakkette wat beskikbaar is deur die pakketbestuurder van elke verspreiding uit die boks. Dus, ons oorweeg slegs pakkette van elke verspreiding se verstek spieëls, ignoreer pakkette van onstabiele bewaarplekke (soos Debian 'toets' spieëls) en derdeparty pakkette (soos Nvidia pakkette van standaard spieëls). Boonop oorweeg ons nie pasgemaakte kernsamestellings of sekuriteitsverharde konfigurasies nie.
Kernelkonfigurasie-analise
Ons het 'n ontledingskrip toegepas gebaseer op . Kom ons kyk na die out-of-the-box beskerming parameters van die genoemde verspreidings en vergelyk dit met die lys van (KSPP). Vir elke konfigurasie-opsie beskryf Tabel 2 die gewenste instelling: die merkblokkie is vir verspreidings wat aan die KSSP-aanbevelings voldoen (sien die volgende vir 'n verduideliking van terme). ; In toekomstige artikels sal ons verduidelik hoeveel van hierdie sekuriteitsmetodes ontstaan het en hoe om 'n stelsel te hack in hul afwesigheid).
Oor die algemeen het die nuwe pitte strenger instellings buite die boks. Byvoorbeeld, CentOS 6.10 en RHEL 6.10 op die 2.6.32-kern kort die meeste van die kritieke kenmerke wat in nuwer pitte geïmplementeer is, soos bv. , streng RWX-toestemmings, adres-randomisering of copy2usr-beskerming. Daar moet kennis geneem word dat baie van die konfigurasie-opsies in die tabel nie in ouer weergawes van die kern beskikbaar is nie en nie in werklikheid van toepassing is nie - dit word steeds in die tabel aangedui as 'n gebrek aan behoorlike beskerming. Net so, as 'n konfigurasie-opsie nie in 'n gegewe weergawe teenwoordig is nie, en sekuriteit vereis dat daardie opsie gedeaktiveer word, word dit as 'n redelike opstelling beskou.
Nog 'n punt om te oorweeg wanneer die resultate geïnterpreteer word: sommige kernkonfigurasies wat die aanvaloppervlak verhoog, kan ook vir sekuriteit gebruik word. Sulke voorbeelde sluit in uprobes en kprobes, kernmodules en BPF/eBPF. Ons aanbeveling is om bogenoemde meganismes te gebruik om werklike beskerming te bied, aangesien dit nie-triviaal is om te gebruik en die uitbuiting daarvan veronderstel dat kwaadwillige akteurs reeds 'n vastrapplek in die stelsel gevestig het. Maar as hierdie opsies geaktiveer is, moet die stelseladministrateur aktief monitor vir misbruik.
As ons verder na die inskrywings in Tabel 2 kyk, sien ons dat moderne pitte verskeie opsies bied om teen die uitbuiting van kwesbaarhede soos inligtinglekkasie en stapel-/hoopoorvloei te beskerm. Ons merk egter op dat selfs die mees onlangse gewilde verspreidings nog nie meer komplekse beskerming geïmplementeer het nie (byvoorbeeld met pleisters ) of moderne beskerming teen kodehergebruikaanvalle (bv. ). Om sake te vererger, beskerm selfs hierdie meer gevorderde verdediging nie teen die volle reeks aanvalle nie. Daarom is dit van kritieke belang vir stelseladministrateurs om slim konfigurasies aan te vul met oplossings wat opsporing en voorkoming van runtime-ontginning bied.
Toepassing Analise
Dit is nie verbasend nie, verskillende verspreidings het verskillende pakketkenmerke, samestellingsopsies, biblioteekafhanklikhede, ens. Verskille bestaan selfs vir verspreidings en pakkette met 'n klein aantal afhanklikhede (byvoorbeeld coreutils op Ubuntu of Debian). Om die verskille te evalueer, het ons alle beskikbare pakkette afgelaai, hul inhoud onttrek en die binaries en afhanklikhede ontleed. Vir elke pakket het ons tred gehou met die ander pakkette waarvan dit afhang, en vir elke binêre het ons die afhanklikhede daarvan opgespoor. In hierdie afdeling som ons die gevolgtrekkings kortliks op.
Verspreidings
In totaal het ons 361 556 pakkette vir alle verspreidings afgelaai en slegs pakkette uit verstekspieëls onttrek. Ons het pakkette geïgnoreer sonder ELF-uitvoerbare, soos bronne, lettertipes, ens. Die verspreiding van pakkette en lêers oor verspreidings word in Fig. 129.
Fig. 3
Jy sal dalk sien dat hoe meer modern die verspreiding is, hoe meer pakkette en binaries bevat dit, wat logies is. Ubuntu- en Debian-pakkette bevat egter baie meer binaries (beide uitvoerbare en dinamiese modules en biblioteke) as CentOS, SUSE en RHEL, wat moontlik die aanvaloppervlak van Ubuntu en Debian beïnvloed (daar moet daarop gelet word dat die nommers alle binaries van alle weergawes weerspieël pakket, dit wil sê, sommige lêers word verskeie kere ontleed). Dit is veral belangrik as jy afhanklikhede tussen pakkette oorweeg. Dus, 'n kwesbaarheid in 'n enkele pakket binêr kan baie dele van die ekosisteem beïnvloed, net soos 'n kwesbare biblioteek alle binaries kan beïnvloed wat dit invoer. As 'n beginpunt, kom ons kyk na die verspreiding van die aantal afhanklikhede tussen pakkette in verskillende bedryfstelsels:
Fig. 4
In byna alle verspreidings het 60% van pakkette ten minste 10 afhanklikhede. Daarbenewens het sommige pakkette 'n aansienlik groter aantal afhanklikhede (meer as 100). Dieselfde geld vir omgekeerde pakketafhanklikhede: soos verwag word, word 'n paar pakkette deur baie ander pakkette in die verspreiding gebruik, so kwesbaarhede in daardie uitgesoekte paar is 'n hoë risiko. As voorbeeld, die volgende tabel lys die 20 pakkette met die maksimum aantal omgekeerde afhanklikhede in SLES, Centos 7, Debian 9 en Ubuntu 18.04 (elke sel dui die pakket en die aantal omgekeerde afhanklikhede aan).
Tabel 3
Interessante feit. Alhoewel alle bedryfstelsels wat ontleed is, vir die x86_64-argitektuur gebou is, en die meeste pakkette die argitektuur het wat as x86_64 en x86 gedefinieer is, bevat pakkette dikwels binaries vir ander argitekture, soos in Figuur 5 getoon. XNUMX.
Fig. 5
In die volgende afdeling sal ons delf na die kenmerke van die geanaliseerde binaries.
Binêre lêerbeskermingstatistieke
Op die absolute minimum moet jy 'n basiese stel sekuriteitsopsies vir jou bestaande binaries ondersoek. Verskeie Linux-verspreidings kom met skrifte wat sulke kontroles uitvoer. Byvoorbeeld, Debian/Ubuntu het so 'n skrif. Hier is 'n voorbeeld van sy 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: yesDie draaiboek kontroleer vyf :
- Posisie-onafhanklike uitvoerbare (PIE): Dui aan of die teksgedeelte van 'n program in die geheue geskuif kan word om ewekansigheid te verkry as ASLR in die kern geaktiveer is.
- Stapelbeskermd: Of stapelkanaries geaktiveer is om teen stapelbotsingsaanvalle te beskerm.
- Versterk Bron: of onveilige funksies (byvoorbeeld strcpy) vervang word met hul veiliger eweknieë, en oproepe wat tydens looptyd gekontroleer is, word vervang met hul ongemerkte eweknieë (byvoorbeeld memcpy in plaas van __memcpy_chk).
- Leesalleen-verskuiwings (RELRO): Of hervestigingstabelinskrywings as leesalleen gemerk is as dit geaktiveer word voordat uitvoering begin.
- Onmiddellike binding: Of die looptydskakelaar alle bewegings toelaat voordat programuitvoering begin (dit is gelykstaande aan 'n volle RELRO).
Is bogenoemde meganismes voldoende? Ongelukkig nee. Daar is bekende maniere om al die bogenoemde verdediging te omseil, maar hoe harder die verdediging, hoe hoër is die lat vir die aanvaller. Byvoorbeeld, moeiliker om toe te pas as PIE en onmiddellike binding in werking is. Net so vereis volledige ASLR bykomende werk om 'n werkende ontginning te skep. Gesofistikeerde aanvallers is egter reeds bereid om aan sulke beskerming te voldoen: hul afwesigheid sal in wese die hack versnel. Dit is dus noodsaaklik dat hierdie maatreëls as nodig geag word minimum.
Ons wou bestudeer hoeveel binêre lêers in die betrokke verspreidings deur hierdie en drie ander metodes beskerm word:
- Onuitvoerbare bietjie () verhoed uitvoering in enige streek wat nie uitvoerbaar behoort te wees nie, soos die stapelhoop, ens.
- dui die uitvoeringspad aan wat deur die dinamiese laaier gebruik word om bypassende biblioteke te vind. Die eerste een is verpligte vir enige moderne stelsel: die afwesigheid daarvan laat aanvallers toe om die loonvrag arbitrêr in die geheue te skryf en dit uit te voer soos dit is. Vir die tweede, verkeerde uitvoeringspadkonfigurasies help met die bekendstelling van onbetroubare kode wat tot 'n aantal probleme kan lei (bv. En ).
- Stapelbotsingsbeskerming bied beskerming teen aanvalle wat veroorsaak dat die stapel ander areas van geheue (soos die hoop) oorvleuel. Gegewe onlangse uitbuiting misbruik , het ons gevoel dit was gepas om hierdie meganisme in ons datastel in te sluit.
So, sonder meer, kom ons kom by die getalle. Tabelle 4 en 5 bevat 'n opsomming van die ontleding van onderskeidelik uitvoerbare lêers en biblioteke van verskeie verspreidings.
- Soos u kan sien, word NX-beskerming oral geïmplementeer, met seldsame uitsonderings. In die besonder kan 'n mens let op die effens laer gebruik daarvan in Ubuntu- en Debian-verspreidings in vergelyking met CentOS, RHEL en OpenSUSE.
- Stapelkanaries ontbreek op baie plekke, veral in verspreidings met ouer pitte. Sommige vordering word gesien in die nuutste verspreidings van Centos, RHEL, Debian en Ubuntu.
- Met die uitsondering van Debian en Ubuntu 18.04, het die meeste verspreidings swak PIE-ondersteuning.
- Stapelbotsingsbeskerming is swak in OpenSUSE, Centos 7 en RHEL 7, en bestaan feitlik nie in ander nie.
- Alle verspreidings met moderne pitte het 'n mate van ondersteuning vir RELRO, met Ubuntu 18.04 die voorloper en Debian wat tweede is.
Soos reeds genoem, is die statistieke in hierdie tabel die gemiddelde vir alle weergawes van die binêre lêer. As jy net na die nuutste weergawes van lêers kyk, sal die getalle anders wees (sien byvoorbeeld ). Boonop toets die meeste verspreidings gewoonlik net die sekuriteit van 'n paar funksies in die binêre wanneer statistieke bereken word, maar ons analise toon die ware persentasie funksies wat verhard is. Daarom, as 5 uit 50 funksies in 'n binêre beskerm word, sal ons dit 'n telling van 0,1 gee, wat ooreenstem met 10% van die funksies wat versterk word.
Tabel 4. Sekuriteitskenmerke vir die uitvoerbare lêers wat in Fig. 3 (implementering van relevante funksies as 'n persentasie van die totale aantal uitvoerbare lêers)
Tabel 5. Sekuriteitskenmerke vir die biblioteke wat in Fig. 3 (implementering van relevante funksies as 'n persentasie van die totale aantal biblioteke)
So is daar vordering? Daar is beslis: dit kan gesien word uit die statistieke vir individuele verspreidings (byvoorbeeld, ), sowel as uit die tabelle hierbo. As 'n voorbeeld in Fig. Figuur 6 toon die implementering van beskermingsmeganismes in drie opeenvolgende verspreidings van Ubuntu LTS 5 (ons het stapelbotsingsbeskermingstatistieke weggelaat). Ons merk op dat van weergawe tot weergawe meer en meer lêers stapelkanaries ondersteun, en ook meer en meer binaries word met volle RELRO-beskerming gestuur.
Fig. 6
Ongelukkig het 'n aantal uitvoerbare lêers in verskillende verspreidings steeds nie enige van die bogenoemde beskermings nie. As u byvoorbeeld na Ubuntu 18.04 kyk, sal u die ngetty-binêre ('n getty-vervanging) sien, sowel as die mksh- en lksh-skulpe, die picolisp-tolk, die nvidia-cuda-toolkit-pakkette ('n gewilde pakket vir GPU-versnelde toepassings) soos masjienleerraamwerke), en klibc -utils. Net so word die mandos-kliënt-binêre ('n administratiewe hulpmiddel wat jou toelaat om outomaties masjiene met geënkripteerde lêerstelsels te herlaai) sowel as rsh-redone-kliënt ('n herimplementering van rsh en rlogin) sonder NX-beskerming gestuur, hoewel hulle SUID-regte het: (Verskeie suid-binaries het ook nie basiese beskerming soos stapelkanaries nie (byvoorbeeld die Xorg.wrap-binêr vanaf die Xorg-pakket).
Samevatting en Slotopmerkings
In hierdie artikel het ons verskeie sekuriteitskenmerke van moderne Linux-verspreidings uitgelig. Die ontleding het getoon dat die jongste Ubuntu LTS-verspreiding (18.04) gemiddeld die sterkste bedryfstelsel- en toepassingsvlakbeskerming implementeer onder verspreidings met relatief nuwe pitte, soos Ubuntu 14.04, 12.04 en Debian 9. Die ondersoekde verspreidings CentOS, RHEL en OpenSUSE in ons stel produseer by verstek 'n digter stel pakkette, en in die nuutste weergawes (CentOS en RHEL) het hulle 'n hoër persentasie stapelbotsingsbeskerming in vergelyking met Debian-gebaseerde mededingers (Debian en Ubuntu). As ons CentOS- en RedHat-weergawes vergelyk, sien ons groot verbeterings in die implementering van stapelkanaries en RELRO vanaf weergawes 6 tot 7, maar CentOS het gemiddeld meer funksies geïmplementeer as RHEL. Oor die algemeen moet alle verspreidings spesiale aandag gee aan PIE-beskerming, wat, met die uitsondering van Debian 9 en Ubuntu 18.04, in minder as 10% van die binaries in ons datastel geïmplementeer word.
Ten slotte moet daarop gelet word dat alhoewel ons die navorsing met die hand gedoen het, daar baie sekuriteitsinstrumente beskikbaar is (bv. , , ), wat analise uitvoer en help om onveilige konfigurasies te vermy. Ongelukkig waarborg selfs sterk beskerming in redelike konfigurasies nie die afwesigheid van uitbuitings nie. Daarom glo ons vas dat dit noodsaaklik is om te verseker , fokus op patrone van uitbuiting en voorkoming daarvan.
Bron: will.com