[0day] Új mérföldkő a biztonságban: Grsecurity a 4.9 Linux kernelhez, világelső teljes CFI-védelemmel a PaX/RAP jóvoltából

Ahogy közel egy éve írtam róla, az IT ipar évtizedek óta küzd a puffer túlcsordulás és a hozzá hasonló memóriakorrupciós hibák ellen. Az információbiztonság offenzív és defenzív oldala örök harcban áll ezeknek a hibáknak a kihasználása miatt. A hacker életműdíjjal is jutalmazott pipacs a PaX Team név mögött, több mint másfél évtizedes munkássága nagy befolyást gyakorolt a szoftveriparra és mára a hardveriparra egyaránt. Fejlesztései nagyban befolyásolták a mai modern operációs rendszerek védelmi képességeit és a legújabb processzorok biztonsági funkcióit. Az ötletei manapság megtalálhatók a legújabb Android, Apple iOS és Windows verziókban egyaránt. A szoftverek azonban egyre bonyolultabbak és univerzalitásuk, funkciógazdagságuk a blackhat hackerek malmára hajtja a vizet. Manapság egy Windows már nagyon sok proaktív biztonsági megoldással rendelkezik, azonban - ahogy a Pwn2Own versenyeken folyamatosan bizonyítják - a rendszerek bonyolultsága és a védelmek tökéletlensége még mindig lehetőséget teremt egy sandbox mechanizmusokkal is ellátott böngésző kompromitációjához és rajta keresztül a teljes oprendszer feletti irányítás átvételéhez.

A lokális privilégium eszkalációs hibák kihasználása ("kernel root exploitok") mára egyre fontosabb kérdéskörré nőtték ki magukat. Volt idő, amikor még mosolyogtunk, hogy két hetente jöttek ki ilyen sebezhetőségek az akkori Linux 2.4 és 2.6 kernelekhez. Manapság a Linux kernel kódbázisa már a sokszorosa az akkoriaknak és így a biztonsági hibák száma is a sokszorosára nőtt. A lokálisan kihasználható kernel hibák értéke pedig szintén nagyságrendekkel emelkedett, ahogy az ipar elkezdte használni az OS-alapú virtualizációs mechanizmusokat és a sandboxing eljárásokat (LXC, Docker és egyéb Linux namespaces alapú szeparációk a "felhőben", seccomp filtering a böngészőkben, androidos selinux korlátozások, stb.). Ezek a virtualizációs technikák és biztonsági megoldások ugyanis könnyedén kijátszhatók egy megfelelő kernel hiba által. Amennyiben egy támadó kódot tud végrehajtani a kernel privilégiumaival, úgy át tudja venni az irányítást a teljes rendszer felett és minden védelmi mechanizmust képes kikapcsolni, egy homokozóból/konténerből pedig ki tud törni és mindenhez hozzáférni.

A kernel önvédelmének biztosítása régóta téma a PaX projektben. 2003-ban először készült a PaX jóvoltából olyan biztonsági megoldás (KERNEXEC), amely megvalósította, hogy a kernel memórialapok vagy írhatók, vagy futtathatók legyenek, de sose mindkettő egyszerre (W^X elv, amelyet az OpenBSD átvett és híressé tett, azonban csak néhány éve sikerült ezt az OpenBSD fejlesztőknek a kernel memóriaterületén is elérniük), így biztosítva azt, hogy egy egyszerű puffer túlcsordulással ne lehessen kapásból kódot futtatni a kernel adatmemória területén. A támadások azonban egyre szofisztikáltabbak lettek és manapság már szinte minden modern operációs rendszer kernele hasonló biztonsági alapokkal rendelkezik, azonban a támadók a már meglévő kódokat felhasználva is rávehetik a kernelt (és bármilyen más programkódot) arra, hogy saját igényeik szerinti sorrendben hajtsák végre azt (ROP - Return Oriented Programming). Ennek megszüntetésére jött létre a PaX RAP biztonsági megoldása, a Reuse Attack Protector, amely most már publikusan is elérhető teljes védelemmel rendelkezik a Linux kernel 4.9 verziójához.

A prweb bejelentés a Grsecurity mögött álló Open Source Security Inc. vállalatról

Eredeti Grsecurity bejelentés itt található a témában.

A 4.9 Linux kernelhez készített patch innen tölthető le.

( nevergone v | 2017. 02. 06., h – 14:54 )

Nagyon jó munka és nagyon jó bejegyzés: köszönöm mindkettőt!

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

( mapee v | 2017. 02. 06., h – 21:17 )

Ha jól értem (köszönhetően pár gyökér, embedded linuxban utazó cégnek) már jó ideje nem érhető el nyíltan (ingyen) a stable grsec kernel patch. Azt tudja valaki, hogy magánszemélyekkel miért nem tesznek kivételt?

( turul16 v | 2017. 02. 10., p – 08:45 )

Varhatolag mennyit kell varni arra, hogy az explit generalo frameworkok
(`noobok` altal is hasznalhato modon) ezt is atugorjak ?

Mi gantalja hogy tortenelem nem ismetli meg onmagat ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ha elolvasod a bejelentést, akkor láthatod, hogy a RAP egy determinisztikus ellenőrzés, amelyik fordításidőben kerül be a programkódokba és indirekt vezérlésátadáskor, valamint visszatéréskor kerül kikényszerítésre (a privát RAP verzió még egy további XOR cookie alapú ret address kódolást is tartalmaz).

Nem lehet automatizáltan kijátszani, mint egy SELinux védelmet, ahol elég egyetlen bit nullára állítása a kernel memóriában, hogy ne legyen enforcing...

Amelyik a weboldalról szabadon elérhető, az a publikus RAP verzió. Az ügyfelek részére van egy még biztonságosabb privát változat is, amely további extra védelmeket tartalmaz és a stabil kernel verziókhoz is elérhetők (jelenleg 3.14 és 4.4 kernelek). Adott Linux disztribúcióhoz is szállítani tud a grsec kész csomagokat az egyszerű telepítéshez és karbantartáshoz.

A bejelentésben látható egy teljesítménymérés és overhead összehasonlítás a Stack Smashing Protector "-all" kapcsolójával szemben. A RAP kisebb teljesítményveszteséget okoz (legrosszabb esetben is csak max. 5.5%-ot), mint az SSP-All, pedig a Stack Smashing Protector (eredeti implementációs nevén "Hiroaki Etoh's ProPolice") nem nyújt teljes CFI-védelmet, kizárólag a vermen található visszatérési értékeket próbálja megvédeni, de azokat se tudja, ha nem szekvenciális puffer túlcsordulásos támadásról van szó, vagy a SSP Guard Canary érték kiolvasható egy infoleak hiba révén. A RAP nem szenved ezektől a gyengeségektől, a védelem nem függ egy Stack Canary változóban tárolt "titoktól".

Mennyivel erosebbb mint a paranoidra confolt main line gcc+linux kernel ?
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Do…

Az utobb 100 kihasznalhato sebezhetosegbol, hanyat vedett volna meg a paranoid mainline/vanilla (hardened), es hanyat a paranoidra confolt +PaX
hogyha a tamado tudja hogy szamitson rajuk ? (Egyaltalan hany olyan hiba volt, hogy az ilyesmi szamitana egyaltalan ..)

A selinux nem a kernel bugjai ellen van.

Majd az ido megvalaszolja, hogy menyire hasznos..
A kovetkezo Linux kernel mar megint lyukas vilagszenzacio cikknel majd vissza terunk ra, a mi foghatta/fogna meg kerdes kornel.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem értelmezhető a kérdés. Egyetlen gcc és linux kernel konfig se véd a ROP támadások ellen... A Clang rendelkezik egy kezdetleges és lassú CFI implementációval, de nem lehet vele hatékonyan védeni a kernelt (sőt leginkább lefordítani se triviális a sok gcc-specifikus kódok miatt, de PaXTeamnek erre is van patche, mert eredetileg Clang/LLVM alapon kezdte el a RAP fejlesztését).

Nyugodtan nézd vissza 14 év távlatából az összes Linux kernel sebezhetőséget. Jelentős részüknél még itt hupon is szóba került, hogy a grsec/PaX véd ellene és adott esetben melyik funkciója fogja meg a támadást.

A RAP nem csak kernel hibák kihasználása ellen jó, hanem bármilyen memória korrupciós hiba kihasználása ellen, ahol a cél kódvégrehajtás. Létezik egy RAP védett Chromium böngésző is a pipacsnál már évek óta, úgyhogy bizonyítottan működik nagy C++ kódbázissal és szintén elhanyagolható teljesítményveszteséget okoz.

A stack protector abszolút nem véd a heapen előforduló memóriakorrupciók ellen. A stacken is csak a lináris túlcsordulásokat tudja megfogni, amelyek egyre ritkábbak manapság. Ma már szinte senki se követ el népszerű szoftverekben 

buf[100];strcpy(buf,argv[1]);

szintű hibákat...