Reference Counter Overflow elleni védelem a PaX-ban

Titkosítás, biztonság, privát szféra

Új védelmi kiegészítéssel bővült az előre mutató, megelőző biztonsági megoldásairól ismert PaX nevű Linux kernel patch. A PAX_REFCOUNT ("Prevent various kernel object reference counter overflows") opció bekapcsolásával lehetőség nyílik a kernel objektumok hivatkozás számlálóinak túlcsordulásából eredő sebezhetőségek kihasználásának észlelésére és megakadályozására.

Ezzel a lépéssel a PaX az UDEREF ("Prevent invalid userland pointer dereference") után egy újabb gyakori programozási hibának a kihasználását képes meggátolni a kernelben.

A megoldás egyelőre tesztelési jelleggel érhető el a 2.6.26.3 verziójú Linux kernelekhez itt, valamint a Grsecurity patch-ben itt.

( dikki | 2008. 08. 25., h – 08:39 )

én nem értek hozzá, és biztos sokszor elhangzott már a kérdés, de: miért nem része a pax a mainline-nak?
rá is google-öztem a kérdésre, de csak egy hupos troll-szálat találtam :-D

Az egyik oka szerintem maga Linus. Ha az OpenBSD-sek onanizáló majmok, akkor a Grsecurity felhaszálók vajon micsodák?
A másik oka a RedHat. Miután a biztonsági cuccok következetesen visszautasításra kerültek, a RedHat mégis benyomta az ExecShield-et, és azóta meg azzal lehet védekezni, hogy az már benne van.

Na megyek vissza a majomházba és onanizálok tovább.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( kisg v | 2008. 08. 25., h – 08:52 )

Vannak olyan tervek, hogy a GRSecurity / PaX valahogy bekerüljön a mainline kernelbe? Tudom, hogy már volt itt szó erről korábban, csak "status update" érdekelne. Azt tudom, hogy van néhány user-space alkalmazás amik nem igazán jól viselik. Pl. az X-nél is ki kell kapcsolni elég sok memóriavédelmi funkciót.
Azonban, az X is fejlődik, és talán már nincs messze a userként futó X szerverek ideje.

Van ezen a fronton valami változás?

Illetve van valamilyen kimutatás, hogy egy GRsecurity-val patchelt és jól beállított rendszer mennyivel ellenállóbb a különböző bugokkal / exploitokkal szemben? Olyasmi listára gondolok, hogy "(kernel) bug - exploit - vanilla nem védett - grsecurity patchelt ABCDE beállításokkal védett.

UDPATE: Most láttam, hogy megelőztek, de most már nem törlöm ki.

Üdv,
Gergely

Az ebből a szempontból nem lenne probléma, mert PaXTeam így is követi a patchekkel az újabb verziókat... :)

Ennek a REFCOUNT védelemnek a bekerülésére egyébként látnék esélyt (lehet fejükhöz csapnak a kernel fejlesztő urak, hogy miért nem gondoltak erre eddig), de persze nem ennek a megoldásnak a beemelésével, hanem majd a Red Hat megint feltalálja a spanyol viaszt és a saját implementációjuk lesz commitolva, ünnepélyes keretek között. :P

Arra is kiváncsi leszek, hogy a többi vendor mikor fogja bejelenteni, mint saját innovációt (like MS, OpenBSD, etc.). Lehet ehhez is kell majd 5-6 év, mint az ASLR-hez...

Ja, igen, erről az oldaláról valóban próbléma, de mainline-ba való bekerülésekor ez változhatna, hisz utána nem csak PaXTeam-nek és spender-nek kellene igazodni minden változtatáshoz, hanem a többi fejlesztőnek is, mert olyan commitok nem kerülhetnének be, amelyektől broken lenne a mainline-ban lévő PaX/grsec. De erről felesleges is beszélni, mert úgyse kerülnek be, nincs érdekében ott senkinek... (és itt megint meglehetne kérdőjelezni, hogy bazár-e a modell, de nem érdemes belemenni :)

Nem bazár. És már nagyon régen nem az. A Linux fejlesztési irányát meghatározó emberek mind nagyipari Linux felhasználók / gyártók alkalmazottai. Esetleg a Linux Foundation-e, amit pedig a nagyipari Linux felhasználók / gyártók tartanak fent.
Ebből két dolog következik:
1. Olyan dolgok és úgy fognak bekerülni a mainline-ba, ami a gyártók érdekeit nem sérti - de legalábbis együtt tudnak élni vele.
2. Ha valaki valamit "be akar nyomni" a mainline-ba, akkor vagy meggyőzi személyesen a kulcsembereket, hogy az milyen jó lesz, vagy letesz egy megfelelő összeget valamelyik nagy gyártónál (effektíve RedHat vagy Novell), hogy neki az X feature kell. Utóbbi esetben a gyártó természetesen vállalni fogja neki, hogy addig, amig nem kerül be, addig csinálnak neki custom kernelt.

Ilyen egyszerű. Ha a GRSecurity community kellően meg lenne támogatva nagyipari Linux felhasználókkal, pikk - pakk be tudna kerülni... :)

Üdv,
Gergely

az X mar evek ota vigan fut PaX alatt, nem tudom, milyen disztrot hasznalsz, de valamit nagyon elbaltaznak, ha barmit is ki kell kapcsolni hozza. az egyetlen, ami gondot okoz, az a binaris driverek, amik futasidoben akarnak kodot generalni (ATI biztos, nvidia-ra mar nem emlekszem, de azt hiszem az is), ott az MPROTECT-et ki kell kapcsolni minden, opengl-t hasznalo progin. ha a /dev/mem vedelemre gondoltal (ami mellesleg mar vanilla kernelben is van, igaz szokas szerint nem egeszen ugy sikerult, ahogy elkepzeltek), az meg X tervezesi hiba, amit sajnos csak eleg lassan sikerul meghegeszteniuk a fejlesztoknek.

nvidia binárisnál is ki kell kapcsolni már a Xorg binárison is a restrict_mprotect()et, mert nem tudja betölteni az nvidia xorg drivert. Bár talán volt, hogy sikerült betölteni, de az alap az, hogy restrict_mprotect() el nemmegy. ...Megnéztem most a pár napja futó X- nél a proc/pid/maps ban van rwx...

De ezzel az nvidia binárissal más baj is van. A 2.6.26.os kernellel a PaX KERNEXEC el mar a suspend to ram is megy alapból, egészen addig, míg az nvidia kernel modul be nem kerül a képbe.

Az "NVRM RmPowermanagement 4/5" nél kifagy. És mivel bináris driver forrás minden nélkül, és a suspend to ramnál ebben a fázisban már log sincs, sőt konzol sincs, (Ez a suspending console folyamat után van) így normál házi eszközökkel (=0 :))) debugolni kb. lehetetlen. A "hiányzó log" visszatéréskor kerül bejegyzésre a syslogba (is).

Viszont sajnos kell a bináris cucc, mert különben nincs rendes 3D, és nincs videó jel a suspend to ram után visszatéréskor a tty1-tty6os konzolokon, tehát az sem megoldás hogy dcop force logout, kdm stop, és rmmod nvidia szundi előtt.

Valószínű, hogy uvesafb-vel lehetne kisérletezni ami kezeli rendes(ebb)en a vbetool-t normál vesafb vel szemben, és/vagy spéci BIOS beállításokkal (restore VGA POST after S3 resume - asus hidden (!!) bios opció), de ehhez jó sokat kellene nyomozni, főleg mert etch ben elvileg nincs benne v86d (?), ami kell a uvesafb nek, tehát azt is backportolni kéne. Ehhez a komplex folyamathoz most valahogy nincs kellő energia :))

Sz'al valami nem kóser ebben az nvidia binárisban, így felhasználóként. Teljesítményre tökjó, meg stabil is, de memóriakezelés terén, meg energiatakarékosság terén, sőt konzol (tty1-tty6) terén nincs egészen rendben.

-------------

r=1 vagyok, de ugatok...

( willy v | 2008. 08. 25., h – 09:14 )

En speciel ruhelenem ha belekerulne a mainline kernelbe.

A mainline kernelben kikapcsolhatod ha nem kell. Ha a disztribútorok szállítanának foo.x.y.z-pax meg foo.x.y.z-generic kernelt, akkor lenne választási lehetőség, így nem zavarná azokat, akiknek mondjuk nem kell. Én spec. helyi hálón üzemelő adatbázis szerverre biztos nem tennék, még ha azt is állítják, hogy elhanyagolható az overhead-je. Ha meg valaki olyan helyre tenné, ahol úgy érzi, hogy kell, akkor telepíti.

--
trey @ gépház

Az UDEREF a szegmentálást használja a védelem megvalósítására. Sajnos az AMD 64 bites kiterjesztés tervezésekor az egész szegmentálásos részt kihagyta (amelyet kénytelen volt átvenni az Intel is kompatibilitási okokból), ezért ott ezzel a módszerrel nem megvalósítható az UDEREF. Lenne rá más módszer (pl. 4:4 split), de az elég nagy overheaddel járna...

Abban lehet esetleg reménykedni, hogy a virtualizációs megoldások felkapottsága miatt a gyártók megegyeznek a szegmentálás x86_64-re való átültetésében, mert ott is szükség lenne rá a jobb izoláció és a nagyobb teljesítmény eléréséhez (kevesebb dolgot kellene emulálni). A Xen fejlesztők jelezték is, hogy szükségük lenne rá, de azóta nem látni előrelépést az ügyben.

akkor lényegében tervezésből fakadó okok miatt nincs UDEREF x86-64-re, ha meg a következő x86-64-es cpu-kba be is kerülne, az mit sem változtatna a jelenleg már forgalomban levő / kint levő cpu-k felépítésén, szóval akkor összességében halott ügy jelenleg.
___
info

Hát, igen...

Egyébként a Linux kernel fejlesztők észbe kaptak a vmsplice exploit után és bár elég bénán, de egy minimális null ptr deref védelmet összetákoltak azért, amelyik az alsó 64k-s címekre nem enged mmapelni. Bár elsőre ez se sikerült nekik tökéletesen, mert kijátszható volt, de aztán spender kijavíttatta a kódot, szóval egy amatőr megoldás azért van már alapból a mostani kernelekben így is, csak az nem védi a teljes címteret, mint a PaX/UDEREF és azoknál a programoknál se működik, amelyek arra az alsó 64k-s területre akarnak mmappelni.

Naja, de ezzel megoltek par dolgot pl wine es dos emuk hasznalatanal, mivel ott vm86 modban ugye a 0-as cimtol (amire a null pointer is mutat a process szempontjabol) kell, hogy cimezheto legyen. Mondjuk engem nem zavar, meg nyilvan ki is lehet kapcsolni, de olvastam sok user anyazast, hogy nem tudjak futtatni regi dos/win miegymas cuccokat itt-ott ...

Igen, ezekre utaltam. A PaX/UDEREF azért 1000x profibb megoldás, mert az egész címteret védi a userland dereference problémáktól és amellett gond nélkül tudnak futni ezek a programok is, mert a problémát a gyökerénél, az illegális kernel->userland pointer hivatkozásoknál fogja meg.

? Hat ha mappeled, akkor mappeled a null pointer problemat is nemcsak vm86-ot ... Vagy ugy erted, hogy csak pl a DOSEMU eseteben? Elvileg az meg oke lenne, hogy vm86 modban mashol legyen, a problemat az okozza, hogy egy emulator mukodese soran (tapasztaltam a dosrun fejlesztese soran anno) vm86 modbol kilep a cucc bizonyos esetekben, es akkor neked kell emulalni az adott dolgot, ami nem mukodne vm86-ban (port I/O pl). Ezzel az a baj, hogy akkor tehat mar nem VM86 modban vagy, megis irnod/olvasnod kell esetleg akar a null pointer-rel mutatott cuccot is. Persze lehetne olyat is, hogy ezt magvaltoztatni: mashova mappelni ezt "normal" modban is, ehhez viszont akkor minden ezt hasznalo cuccot modositani kell (dosemu, wine, mittomen') mivel nem lesz tobbe kompatibilis a cucc.

( NagyZ v | 2008. 08. 25., h – 12:01 )

kene mar tartani egy eloadast az ilyen sebezhetosegekrol es ezek kihasznalasarol, gyakorlati kodokkal es magyarazattal :)

gondoltam hogy idei hactivityre irok nekik,hogy ugyan mi lenne ha, de

- erre nem en vagyok a legmegfelelobb, azthiszem, van itt 3-4 ember aki jobban vagja ezt (paxteam, Hunger, hm, ki me'g? :))
- nem tudom magyarorszagon ez mennyire "sotet zona"

max titokban egyik lokalkommuna talalkozon :D

Mert paranoiás vagy? ;)) Pedig most egészen komolyan gondoltam, a smiley nem az irónia miatt volt ott. Egy ilyen érdekelne és szívesen tanulok (ezen a téren is) a nálam tapasztaltabbaktól és bölcsebbektől.

--
Ruby takes the elegance and simplicity of Perl, and mixes it with the library support of Lisp.

Szerintem ez nem sötét zóna egyáltalán.

Én akár valamelyik egyetem nagyelőadóját is el tudnám képzelni mint helyszínt.
Valójában az a szomorú, hogy a biztonságos programozási technikák csak olyan szinten vannak érintve az oktatásban, hogy "az strcpy rossz, mert buffer overflow lehet belőle". A szoftverfejlesztéssel foglalkozók nagyon nagy részének nagyon alacsony a biztonsággal kapcsolatos képzettsége. És itt nem csak Unix/Linuxra gondolok, hanem bármilyen platformra.

Én olyan előadást / előadásokat képzelnék el, ahol egyrészt be lennének mutatva a sebezhetőségek, azok kihasználása, és hogy hogyan lehet ellenük védekezni egyrészt a különböző biztonság(érzet) növelő eszközök beállításával (PaX, execshield, SELinux, AppArmor ...), másrészt a programok megfelelő minőségű megírásával (POSIX / BSD / Linux APIk helyes használata, kerülendő eszközök ...stb.).

Szerintem, ha előadót / előadókat találunk, akkor helyszín + érdeklődő is akad. Biztos vagyok benne, hogy egy ilyen kezdeményezéshez szponzorokat is lehet találni.

Üdv,
Gergely

oktobertol indul az ELTE -n google tech talks szeru dolog, majd beszelek a tobbiekkel nekik hogy tetszik :)

a hup communityt ugyse erdekli, mert foleg microsoftos technologiakrol lesz eloadas (EF, LINQ/DLINQ, .NET 3.5), de ha eztis beletudjuk
bujtatni (megs zerintem amugyis), akkor bekuldom majd hirkent a helyet, idot, eloadokat, etc

Szerintem többeket érdekelnének az MS közeli technológiák is. Már csak a nyálcsorgatás / szörnyülködés (ízlés szerint) végett. :)
Meg az ember előbb utóbb kinövi az "anti M$" korszakát, és viszonylag gyakran fut bele abba, hogy multiplatform / Windowsos dolgokat kell fejlesztenie.

Van / lesz ennek a cuccnak honlapja?

Akartam eloadast tartani hacktivity-n ezekrol a dolgokrol, de sajnos munka miatt nincs ra idom. Van egy draftom de nem fogok eljutni odaig, hogy call for paper-re be tudjam adni. Hacktivity amugy sem celkozonseg (azert aki jon az irja meg, mert hup-rol security-minded emberekkel meg nem talalkoztam eloben).

Hibatipusokrol talalsz infot itt:
http://cwe.mitre.org/data/slices/2000.html

egeszen jo osszegyujtott anyagok vannak itt:
http://www.orkspace.net/secdocs/

meg persze a phrack:
http://www.phrack.org/

Aki kivesezte ezt a temat es nagyon tetszett az egy Ilja Van Sprundel nevu faszi (http://blogs.23.nu/ilja), o talalt mar hibat sok mindenben. Ami erdekes tole az az "Unusual bugs" eloadasa (http://ilja.netric.org/files/Unusual%20bugs.pdf).

Ebben vannak nagyon franko tenyleg ritka dolgok (NULL-pointer dereftol a FD table manipulalasig).

Remelem segitettem ;)

synapse

--------------------------
The OOM killer is like a surgeon that amputates the limb of a man to save his life: losing a limb is not a nice thing, but sometimes there is nothing better to do.

"Understanding the Linux Kernel" on page frame reclaiming

Erre én is subscribe.

Valamelyik Linux konferencián tartott volna a tesóm (vagy tartott is?) előadást ilyen és ehhez kapcsolódó (PIE, SSP) témakörökben. Sajnos csak jövőre jön megint haza úgy néz ki. Ilyen az élet.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."