TL, DR. Ebben a cikkben megvizsgáljuk azokat a keményítési sémákat, amelyek öt népszerű Linux-disztribúción már a dobozból kiindulva működnek. Mindegyikhez az alapértelmezett kernelkonfigurációt vettük, betöltöttük az összes csomagot, és elemeztük a biztonsági sémákat a csatolt binárisokban. A figyelembe vett disztribúciók az OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 és 7, valamint az Ubuntu 14.04, 12.04 és 18.04 LTS.
Az eredmények megerősítik, hogy még az olyan alapvető sémákat sem mindenki fogadta el, mint a kanárik egymásra rakása és a pozíciófüggetlen kód. Még rosszabb a helyzet a fordítók számára, ha olyan sebezhetőségekről van szó, mint például a verem összecsapása, amely januárban került a figyelem középpontjába a publikálás után. . De nem minden olyan reménytelen. A binárisok jelentős része alapvető védelmi módszereket valósít meg, és számuk verzióról verzióra nő.
Az áttekintés kimutatta, hogy a legtöbb védelmi módszert az Ubuntu 18.04-ben implementálták operációs rendszer és alkalmazásszinten, ezt követi a Debian 9. Másrészt az OpenSUSE 12.4, CentOS 7 és RHEL 7 alapvető védelmi sémákat és verem-ütközésvédelmet is megvalósít. sokkal sűrűbb alapértelmezett csomagkészlettel még szélesebb körben használatos.
Bevezetés
Nehéz jó minőségű szoftvert biztosítani. A statikus kódelemzésre és a dinamikus futásidejű elemzésre szolgáló nagyszámú fejlett eszköz, valamint a fordítók és programozási nyelvek fejlesztésében elért jelentős előrelépés ellenére a modern szoftverek továbbra is szenvednek a támadók által folyamatosan kihasznált sebezhetőségektől. A helyzet még rosszabb az örökölt kódot tartalmazó ökoszisztémákban. Ilyenkor nemcsak a lehetséges kihasználható hibák megtalálásának örök problémájával kell szembenéznünk, hanem szigorú visszamenőleges kompatibilitási keretrendszerek is korlátoznak bennünket, amelyek gyakran megkövetelik a korlátozott, vagy ami még rosszabb, sebezhető vagy hibás kód megőrzését.
Itt jönnek képbe a programok védelmének vagy keményítésének módszerei. Bizonyos típusú hibákat nem tudunk megelőzni, de megnehezíthetjük a támadó életét és részben megoldhatjuk a problémát megelőzéssel vagy megelőzéssel. kizsákmányolás ezeket a hibákat. Az ilyen védelmet minden modern operációs rendszer alkalmazza, de a módszerek összetettségükben, hatékonyságukban és teljesítményükben nagymértékben különböznek egymástól: a stack kanáriktól és teljes védelemre и . Ebben a cikkben megvizsgáljuk, hogy az alapértelmezett konfigurációban milyen védelmi módszereket használnak a legnépszerűbb Linux-disztribúciókban, és megvizsgáljuk az egyes disztribúciók csomagkezelő rendszerein keresztül terjesztett binárisok tulajdonságait is.
CVE és biztonság
Mindannyian láttunk olyan cikkeket, amelyek címe „Az év legsebezhetőbb alkalmazásai” vagy „A legsebezhetőbb operációs rendszerek”. Általában statisztikát adnak a biztonsági résekkel kapcsolatos rekordok teljes számáról, mint például , megszerzett valahonnan -tól és egyéb forrásokból. Ezt követően ezeket az alkalmazásokat vagy operációs rendszereket a CVE-k száma alapján rangsorolják. Sajnos, bár a CVE-k nagyon hasznosak a problémák nyomon követésére, valamint a szállítók és felhasználók tájékoztatására, keveset mondanak el a szoftver tényleges biztonságáról.
Példaként vegyük figyelembe a CVE-k teljes számát az elmúlt négy évben a Linux kernel és az öt legnépszerűbb szerver disztribúció, nevezetesen az Ubuntu, a Debian, a Red Hat Enterprise Linux és az OpenSUSE esetében.
Fig. 1
Mit mond nekünk ez a grafikon? A CVE-k nagyobb száma azt jelenti, hogy az egyik disztribúció sebezhetőbb, mint a másik? Nincs válasz. Ebben a cikkben például látni fogja, hogy a Debian erősebb biztonsági mechanizmusokkal rendelkezik, mint például az OpenSUSE vagy a RedHat Linux, és mégis több CVE-vel rendelkezik. Ezek azonban nem feltétlenül jelentenek gyengült biztonságot: még a CVE jelenléte sem jelzi, hogy a sérülékenység fennáll-e. kihasználva. A súlyossági pontszámok jelzik, hogyan valószínűleg egy sebezhetőség kihasználása, de végső soron a kihasználhatóság nagymértékben függ az érintett rendszerekben lévő védelemtől, valamint a támadók erőforrásaitól és képességeitől. Ráadásul a CVE-jelentések hiánya semmit sem mond másokról nem regisztrált vagy ismeretlen sebezhetőségek. A CVE különbsége a szoftver minőségén kívül más tényezőknek is köszönhető, ideértve a teszteléshez allokált erőforrásokat vagy a felhasználói bázis méretét. Példánkban a Debian nagyobb számú CVE-je egyszerűen azt jelezheti, hogy a Debian több szoftvercsomagot szállít.
Természetesen a CVE rendszer hasznos információkkal szolgál, amelyek lehetővé teszik a megfelelő védelmek létrehozását. Minél jobban megértjük a program meghibásodásának okait, annál könnyebben azonosítjuk a lehetséges kihasználási módszereket és kidolgozzuk a megfelelő mechanizmusokat. észlelés és válaszadás. ábrán. A 2. ábra az összes disztribúció sebezhetőségi kategóriáit mutatja az elmúlt négy év során (). Azonnal világos, hogy a legtöbb CVE a következő kategóriákba sorolható: szolgáltatásmegtagadás (DoS), kódvégrehajtás, túlcsordulás, memóriasérülés, információszivárgás (kiszűrés) és a jogosultságok eszkalációja. Bár sok CVE-t többször is beszámítanak különböző kategóriákban, általában ugyanazok a problémák évről évre fennállnak. A cikk következő részében értékeljük a különféle védelmi sémák használatát a sérülékenységek kihasználásának megakadályozására.
Fig. 2
feladatok
Cikkünkben a következő kérdésekre kívánunk választ adni:
- Mi a biztonsága a különböző Linux disztribúcióknak? Milyen védelmi mechanizmusok léteznek a kernel- és felhasználói téralkalmazásokban?
- Hogyan változott a biztonsági mechanizmusok alkalmazása az idők során a disztribúciók között?
- Mekkora a csomagok és könyvtárak átlagos függősége az egyes terjesztéseknél?
- Milyen védelmet alkalmaznak az egyes binárisok?
Elosztások kiválasztása
Kiderült, hogy nehéz pontos statisztikákat találni a terjesztési telepítésekről, mivel a legtöbb esetben a letöltések száma nem jelzi a tényleges telepítések számát. A Unix-változatok azonban a szerverrendszerek többségét teszik ki (a webszervereken 69,2%, a W3techs és más források), arányuk pedig folyamatosan növekszik. Így kutatásunk során azokra a disztribúciókra összpontosítottunk, amelyek a platformon azonnal elérhetők . Különösen a következő operációs rendszert választottuk:
Elosztás/verzió
A mag
Épít
OpenSUSE 12.4
4.12.14-95.3-alapértelmezett
#1 SMP, 5. december 06., szerda 00:48:2018 UTC (63a8d29)
Debian 9 (nyúló)
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 15. január 17. kedd, 07:28:2019 UTC
7 CentOS
3.10.0-957.5.1.el7.x86_64
#1 SMP, 1. február 14. péntek, 54:57:2019 UTC
Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP, szerda, november 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 15. november 17. csütörtök, 36:42:2018 UTC
Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-általános
#166~14.04.1-Ubuntu SMP, szombat, november 17., 01:52:43 UTC 20…
Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP 7. december 09. péntek, 59:47:2018 UTC
Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27 – Ubuntu SMP 6. december 18. csütörtök, 27:01:2018 UTC
Táblázat 1
Elemzés
Tanulmányozzuk az alapértelmezett kernelkonfigurációt, valamint az egyes disztribúciók csomagkezelőjén keresztül elérhető csomagok tulajdonságait. Így csak az egyes disztribúciók alapértelmezett tükrözőiből származó csomagokat vesszük figyelembe, figyelmen kívül hagyva az instabil tárolókból származó csomagokat (mint például a Debian „tesztelő” tükrök) és a harmadik féltől származó csomagokat (például a szabványos tükrök Nvidia csomagjait). Ezenkívül nem vesszük figyelembe az egyéni kernel-összeállításokat vagy a megerősített biztonsági konfigurációkat.
Kernel konfiguráció elemzése
alapján egy elemző szkriptet alkalmaztunk . Nézzük meg a megnevezett disztribúciók készenléti védelmi paramétereit, és hasonlítsuk össze őket a listából (KSPP). A 2. táblázat minden konfigurációs beállításnál leírja a kívánt beállítást: a jelölőnégyzet azokra a disztribúciókra vonatkozik, amelyek megfelelnek a KSSP ajánlásainak (a kifejezések magyarázatát az alábbiakban találja). ; A következő cikkekben elmagyarázzuk, hogy hány ilyen biztonsági módszer jött létre, és hogyan lehet feltörni egy rendszert ezek hiányában).
Általánosságban elmondható, hogy az új kernelek szigorúbb beállításokkal rendelkeznek. Például a 6.10-es kernelen lévő CentOS 6.10 és RHEL 2.6.32 hiányzik az újabb kernelekben megvalósított kritikus funkciók többségétől, mint pl. , szigorú RWX engedélyek, cím randomizálás vagy copy2usr védelem. Meg kell jegyezni, hogy a táblázatban szereplő konfigurációs lehetőségek közül sok nem érhető el a kernel régebbi verzióiban, és a valóságban nem alkalmazható – ez a táblázatban továbbra is a megfelelő védelem hiányaként szerepel. Hasonlóképpen, ha egy konfigurációs opció nem található meg egy adott verzióban, és a biztonság megköveteli, hogy az opciót le kell tiltani, ez ésszerű konfigurációnak minősül.
Egy másik szempont, amelyet figyelembe kell venni az eredmények értelmezésekor: bizonyos kernelkonfigurációk, amelyek növelik a támadási felületet, szintén használhatók a biztonság érdekében. Ilyen például az uprobes és a kprobes, a kernel modulok és a BPF/eBPF. Javasoljuk, hogy a fenti mechanizmusokat használja a valódi védelem érdekében, mivel ezek használata nem triviális, és kihasználásuk feltételezi, hogy a rosszindulatú szereplők már megvették a lábukat a rendszerben. De ha ezek a beállítások engedélyezve vannak, a rendszergazdának aktívan figyelnie kell a visszaéléseket.
Ha tovább nézzük a 2. táblázat bejegyzéseit, azt látjuk, hogy a modern kernelek számos lehetőséget kínálnak a sérülékenységek, például az információszivárgás és a verem/halom túlcsordulás elleni védelemre. Azonban észrevesszük, hogy még a legújabb népszerű disztribúciók sem valósítottak meg összetettebb védelmet (például javításokkal ) vagy modern védelem a kód újrafelhasználási támadásai ellen (pl. ). A helyzetet rontja, hogy még ezek a fejlettebb védelmek sem védenek a támadások teljes skálájával szemben. Ezért rendkívül fontos, hogy a rendszergazdák az intelligens konfigurációkat olyan megoldásokkal egészítsék ki, amelyek futásidejű kihasználások észlelését és megelőzését kínálják.
Alkalmazáselemzés
Nem meglepő, hogy a különböző disztribúciók eltérő csomagjellemzőkkel, fordítási opciókkal, könyvtárfüggőkkel stb. rendelkeznek. Különbségek vannak még a disztribúciók és csomagok kis számú függőséggel (például coreutils Ubuntu vagy Debian). A különbségek értékeléséhez letöltöttük az összes elérhető csomagot, kibontottuk azok tartalmát, és elemeztük a binárisokat és a függőségeket. Minden egyes csomagnál nyomon követtük a többi csomagot, amelytől függ, és minden bináris esetében követtük a függőségeit. Ebben a részben röviden összefoglaljuk a következtetéseket.
disztribúciók
Összesen 361 556 csomagot töltöttünk le az összes disztribúcióhoz, és csak a csomagokat vontuk ki az alapértelmezett tükrökből. Figyelmen kívül hagytuk az ELF végrehajtható fájlokat nem tartalmazó csomagokat, például forrásokat, fontokat stb. A szűrés után 129 569 csomag maradt, amelyek összesen 584 457 bináris fájlt tartalmaznak. A csomagok és fájlok disztribúciók közötti eloszlását az ábra mutatja. 3.
Fig. 3
Észreveheti, hogy minél modernebb a disztribúció, annál több csomagot és bináris fájlt tartalmaz, ami logikus. Az Ubuntu és Debian csomagok azonban sokkal több binárist tartalmaznak (mind a végrehajtható fájlokat, mind a dinamikus modulokat és könyvtárakat), mint a CentOS, SUSE és RHEL, ami potenciálisan hatással lehet az Ubuntu és a Debian támadási felületére (megjegyzendő, hogy a számok az összes verzió összes binárisát tükrözik csomagot, azaz egyes fájlokat többször is elemzik). Ez különösen fontos, ha figyelembe vesszük a csomagok közötti függőséget. Így az egyetlen csomag bináris fájljában lévő sebezhetőség az ökoszisztéma számos részére hatással lehet, ahogy a sérülékeny könyvtár is érintheti az összes importáló bináris fájlt. Kiindulásként nézzük meg a függőségek számának megoszlását a csomagok között a különböző operációs rendszerekben:
Fig. 4
Szinte minden disztribúcióban a csomagok 60%-a legalább 10 függőséggel rendelkezik. Ezenkívül egyes csomagok lényegesen nagyobb számú függőséget tartalmaznak (több mint 100). Ugyanez vonatkozik a fordított csomagfüggőségre is: ahogy az várható volt, néhány csomagot sok más csomag is használ a disztribúcióban, így a kiválasztott néhány csomag sebezhetősége nagy kockázatot jelent. Példaként a következő táblázat felsorolja azt a 20 csomagot, amelyekben a fordított függőségek maximális száma SLES, Centos 7, Debian 9 és Ubuntu 18.04 (minden cella a csomagot és a fordított függőségek számát jelzi).
Táblázat 3
Érdekes tény. Bár az összes elemzett operációs rendszer az x86_64 architektúrára készült, és a legtöbb csomag architektúrája x86_64 és x86, a csomagok gyakran tartalmaznak bináris fájlokat más architektúrákhoz, amint az 5. ábrán látható. XNUMX.
Fig. 5
A következő részben az elemzett binárisok jellemzőivel foglalkozunk.
Bináris fájlvédelmi statisztikák
Az abszolút minimumot meg kell vizsgálnia a meglévő binárisok alapvető biztonsági beállításaival. Számos Linux disztribúció rendelkezik olyan szkriptekkel, amelyek ilyen ellenőrzéseket végeznek. Például a Debian/Ubuntu rendelkezik ilyen szkripttel. Íme egy példa a munkájára:
$ 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: yesA forgatókönyv ötöt ellenőriz :
- Pozíciófüggetlen végrehajtható (PIE): Azt jelzi, hogy a program szöveges része mozgatható-e a memóriában a véletlenszerűvé tétel érdekében, ha az ASLR engedélyezve van a kernelben.
- Veremvédelem: engedélyezve van-e a veremben lévő kanárik védelme a verem ütközési támadásai ellen.
- Fortify Source: a nem biztonságos funkciókat (például strcpy) lecserélik-e biztonságosabb megfelelőire, és a futás közben ellenőrzött hívásokat a nem ellenőrzött megfelelőkre (például memcpy a __memcpy_chk helyett).
- Csak olvasható áthelyezések (RELRO): Az áthelyezési tábla bejegyzései csak olvashatóként vannak-e megjelölve, ha a végrehajtás megkezdése előtt aktiválódnak.
- Azonnali kötés: A futásidejű linker engedélyezi-e az összes mozgást a programvégrehajtás megkezdése előtt (ez egy teljes RELRO-nak felel meg).
A fenti mechanizmusok elegendőek? Sajnos nincs. Ismertek módszerek a fenti védelem megkerülésére, de minél keményebb a védekezés, annál magasabb a léc a támadó számára. Például, nehezebb alkalmazni, ha PIE és azonnali kötés van érvényben. Hasonlóképpen, a teljes ASLR további munkát igényel egy működő exploit létrehozásához. A kifinomult támadók azonban már felkészültek az ilyen védelemre: hiányuk lényegében felgyorsítja a feltörést. Ezért elengedhetetlen, hogy ezeket az intézkedéseket szükségesnek tekintsék minimum.
Meg akartuk vizsgálni, hogy a kérdéses disztribúciókban hány bináris fájl védett ezekkel és három másik módszerrel:
- Nem végrehajtható bit () megakadályozza a végrehajtást minden olyan régióban, amely nem lehet végrehajtható, például a verem kupacban stb.
- a dinamikus betöltő által a megfelelő könyvtárak megtalálásához használt végrehajtási útvonalat jelöli. Az első az kötelező minden modern rendszer esetében: hiánya lehetővé teszi a támadók számára, hogy tetszőlegesen beírják a hasznos adatokat a memóriába, és úgy hajtsák végre, ahogy van. A második esetben a nem megfelelő végrehajtási útvonal-konfigurációk segítenek megbízhatatlan kód bevezetésében, ami számos problémához vezethet (pl. És ).
- A veremütközés elleni védelem védelmet nyújt az olyan támadások ellen, amelyek miatt a verem átfedi a memória más területeit (például a kupacot). Tekintettel a közelmúltbeli visszaélésekre , úgy éreztük, helyénvaló, hogy ezt a mechanizmust belefoglaljuk adatkészletünkbe.
Szóval minden további nélkül térjünk rá a számokra. A 4. és 5. táblázat összefoglalja a különböző disztribúciók futtatható fájlok és könyvtárai elemzését.
- Mint látható, az NX védelmet ritka kivételektől eltekintve mindenhol megvalósítják. Különösen megjegyzendő, hogy az Ubuntu és a Debian disztribúciókban valamivel alacsonyabb a felhasználása, mint a CentOS, RHEL és OpenSUSE.
- A veremkanárik sok helyen hiányoznak, különösen a régebbi kernelekkel rendelkező disztribúciókban. Némi előrelépés tapasztalható a Centos, RHEL, Debian és Ubuntu legújabb disztribúcióiban.
- A Debian és az Ubuntu 18.04 kivételével a legtöbb disztribúció gyenge PIE-támogatással rendelkezik.
- A veremütközés elleni védelem gyenge az OpenSUSE-ban, a Centos 7-ben és az RHEL 7-ben, míg másokban gyakorlatilag nem létezik.
- Minden modern kernellel rendelkező disztribúció támogatja a RELRO-t, az Ubuntu 18.04 vezet az élen, a Debian pedig a második.
Amint már említettük, a táblázatban szereplő mutatók a bináris fájl összes verziójának átlagát jelentik. Ha csak a fájlok legújabb verzióit nézi, a számok eltérőek lesznek (például lásd ). Sőt, a legtöbb disztribúció jellemzően csak néhány bináris függvény biztonságát teszteli a statisztikák kiszámításakor, de elemzésünk megmutatja a megerősített függvények valódi százalékát. Ezért ha 5 függvényből 50 binárisan védett, akkor 0,1-et adunk, ami a megerősített függvények 10%-ának felel meg.
4. táblázat: Az ábrán látható végrehajtható fájlok biztonsági jellemzői. 3 (a releváns funkciók megvalósítása a végrehajtható fájlok teljes számának százalékában)
5. táblázat: Az ábrán látható könyvtárak biztonsági jellemzői. 3 (a releváns funkciók megvalósítása a könyvtárak teljes számának százalékában)
Tehát van előrelépés? Határozottan van: ez látható az egyes eloszlások statisztikáiból (pl. ), valamint a fenti táblázatokból. Példaként az ábrán. A 6. ábra a védelmi mechanizmusok megvalósítását mutatja az Ubuntu LTS 5 három egymást követő disztribúciójában (kihagytuk a verem ütközésvédelmi statisztikáit). Észrevesszük, hogy verzióról verzióra egyre több fájl támogatja a stack canaries-t, és egyre több binárist is szállítanak teljes RELRO védelemmel.
Fig. 6
Sajnos számos különböző disztribúcióban lévő futtatható fájl még mindig nem rendelkezik a fenti védelemmel. Például, ha az Ubuntu 18.04-et nézi, észre fogja venni az ngetty binárist (a getty csere), valamint az mksh és lksh shelleket, a picolisp értelmezőt, az nvidia-cuda-toolkit csomagokat (népszerű csomag a GPU-gyorsított alkalmazásokhoz). például a gépi tanulási keretrendszerek) és a klibc -utils. Hasonlóképpen, a mandos-client bináris (egy adminisztrációs eszköz, amely lehetővé teszi a titkosított fájlrendszerű gépek automatikus újraindítását), valamint az rsh-redone-client (az rsh és az rlogin újraimplementációja) NX-védelem nélkül érkezik, bár SUID-jogokkal rendelkeznek: (. Ezen kívül számos suid binárisból hiányzik az alapvető védelem, mint például a stack canaries (például az Xorg csomagból származó Xorg.wrap bináris).
Összefoglaló és záró megjegyzések
Ebben a cikkben a modern Linux disztribúciók számos biztonsági funkcióját emeltük ki. Az elemzés kimutatta, hogy a legújabb Ubuntu LTS disztribúció (18.04) valósítja meg átlagosan a legerősebb operációs rendszer és alkalmazás szintű védelmet a viszonylag új kernelekkel rendelkező disztribúciók között, mint például az Ubuntu 14.04, 12.04 és Debian 9. A vizsgált disztribúciók azonban a CentOS, RHEL és A mi készletünkben az OpenSUSE alapértelmezés szerint sűrűbb csomagkészletet produkál, és a legújabb verziókban (CentOS és RHEL) magasabb százalékos veremütközés-védelemmel rendelkeznek, mint a Debian-alapú versenytársak (Debian és Ubuntu). A CentOS és a RedHat verziók összehasonlítása során jelentős javulást tapasztaltunk a stack canaries és a RELRO megvalósításában a 6-os és 7-es verziók között, de átlagosan a CentOS több funkcióval rendelkezik, mint az RHEL. Általánosságban elmondható, hogy minden disztribúciónak különös figyelmet kell fordítania a PIE védelemre, amely a Debian 9 és az Ubuntu 18.04 kivételével az adatkészletünk bináris fájljainak kevesebb mint 10%-ában van implementálva.
Végül meg kell jegyezni, hogy bár a kutatást manuálisan végeztük, számos biztonsági eszköz áll rendelkezésre (pl. , , ), amelyek elemzést végeznek, és segítenek elkerülni a nem biztonságos konfigurációkat. Sajnos még az ésszerű konfigurációk melletti erős védelem sem garantálja a kihasználások hiányát. Éppen ezért határozottan hiszünk abban, hogy létfontosságú biztosítani , a kizsákmányolás mintáira és azok megelőzésére összpontosítva.
Forrás: will.com