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
- Hunger blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
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…
- A hozzászóláshoz be kell jelentkezni
Pipacs = Hunger ? ;)
--
robyboy
- A hozzászóláshoz be kell jelentkezni
nope, Pipacs == PaX Team ;)
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
mert a GPL sem tesz
- A hozzászóláshoz be kell jelentkezni
Lemaradtam. Miért nem érhető el néhány beágyazott Linuxban érdekelt cég miatt ingyen, nyíltan a grsec?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
http://hup.hu/cikkek/20150827/a_grsecurity_felfuggeszti_a_stable_patche…
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nice try... Mesélj a történelemből néhány "explit" generáló frameworköt, amely univerzális kikerülési technikát tartalmaz _bármely_ PaX funkcióra. ;)
- A hozzászóláshoz be kell jelentkezni
ROP -et segito scriptek vannak, nem full auto,
ASLR (extrak), NX , W^X elvileg PaX funkcio(k) (volt(ak)) .
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Az hogy a PaX ötleteket lenyúlták és Cargo Cult módon újraimplementálták szarul az nem a PaXot minősíti.
PaX ASLR != Windows ASLR
PaX PAGEEXEC != OpenBSD W^X
ahogy a Clang CFI != PaX RAP
Van még más okosság is a tarsolyodban?
- A hozzászóláshoz be kell jelentkezni
Nem, nem, csak feliratkozni akkartam.
2 ev mulva meg latjuk mi lesz.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
„privát RAP verzió”
Ezt tartalmazza a jelenlegi patch? A patch alkalmazása kb. milyen teljesítményvesztéssel jár?
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
- A hozzászóláshoz be kell jelentkezni
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".
- A hozzászóláshoz be kell jelentkezni
Köszönöm a választ! Megpróbálom elérni az egyik projektnél, hogy támogassák a grsec fejlesztését, cserébe a privát patch-ért.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Meggyozoen hangzik, koszi.
Nekem a mezei stack protector is tobbnek tunik a semminel. ;-)
Van valahol pelda asm kod, extension `elotte` es `utana` ?
Ahol lehet latni hogy mi es hogyan kerul oda anelkul, hogy letoltenenk ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
IT'S ALIVE
- A hozzászóláshoz be kell jelentkezni
Udv ujra itt ;-)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
van esetleg valami prognózis a végzetes lefolyású betegséged jelenlegi állapotára nézve?
- A hozzászóláshoz be kell jelentkezni