Hivatalos álláspont az állítólagos "grsecurity/PaX sebezhetőséggel" kapcsolatban

Bug

A tegnapi napon írtam arról, hogy a Digital Armaments nevű cég azt állítja, hogy helyileg és távolról is kihasználható "grsecurity/PaX" sebezhetőségek infói vannak a birtokában, de ezeket az infókat csak prémium előfizetőinek adja át. Brad Spengler, a grsecurity mögött álló "spender" tegnap hivatalos állásfoglalást adott ki az állítólagos sebezhetőségről. A bejelentésben FUD-nak nevezte az állításokat. Leírta, hogy ez az a cég, amely saját állítása szerint rendelkezik a 2.6-os Linux kernelhez távolról kihasználható sebezhetőség infóival, de azokat sose hozta napvilágra. Továbbá a cég által megnevezett függvény egy egyszerű függvény, azt könnyen lehet ellenőrizni sebezhetőség szempontjából. Spender szerint a "cég" csak megpróbálja lehúzni az embereket, cégeket, hogy azok fizessenek.

( muczy v | 2007. 01. 13., szo – 08:48 )

/me szereti az ilyen cégeket...

Gentoo Karvaly

( Troppauer | 2007. 01. 13., szo – 08:58 )

Sziasztok,

Azt tudja valaki, hogy a grsec-et miert nem teszik bele a kernel main line-ba, hogy ne keljen patch-cselni (szarakodni) allandoan ?

Biztos megvan az oka.

Pl. SE-Linux benne van a kernelben, RSBAC meg nincs. Pedig a kettő közül az a jobb.

Régebben, még amikor elindultak az ilyen stack overflow protection patch-ek, még az volt egyszer Linus mondása, hogy nem akarja, hogy benne legyen a vanillában, mert akkor majd az exploit gyárak ezt figyelembe veszik, inkább írjanak az emberek jó programokat.

Ez persze szerintem hülyeség. :-)

G

Egyebkent milyen helyen/korulmenyek mellett erdemes hasznalni grsec-et?
Egy ideig hasznaltam a sajat gepemen, igaz elsosorban azert, hogy megismerjem.
Utobbi idoben viszont nem latom ertelmet sajat kernel forditasnak, mert minden mukodik, es sebessegben nem terul meg a befektetett munka. A biztonsagot is megfelelonek tartom kulon pach-ek nekul. Persze lehet, hogy rosszul tudom.

Kesobbi hozzaszolasokbol kiderul, hogy a kulso patch-ekbe meg a nemzetbiztonsag szakemberei irhattak bele (Igaz toluk tartok legkevesbe)... Aztan hogy a kulso patch is tartalmaznak hibakat, ami ujabb biztonsagi kockazat.
Ezek szerint az egy nagy tevhit, hogy a Linux biztonsagosab, mint a M$ Win. Win alatt is nagy mertekben lehet novelni a biztonsagot ha nem Adminisztratorkent hasznlja az ember, es a policy beállításokkal korlátozásokat ir elo.

Kesobbi hozzaszolasokbol kiderul, hogy a kulso patch-ekbe meg a nemzetbiztonsag szakemberei irhattak bele (Igaz toluk tartok legkevesbe)...

Ezért szokott security témakörben az első kérdés lenni, hogy kiktől szeretnéd megvédeni a rendszert. Mondjuk az említett emberektől valószínűleg egyébként sem sikerülne.

Aztan hogy a kulso patch is tartalmaznak hibakat, ami ujabb biztonsagi kockazat.

Nem csak a külső.

Ezek szerint az egy nagy tevhit, hogy a Linux biztonsagosab, mint a M$ Win.

Nem is mondtam ilyet sosem, igaz az ellenkezőjét sem. Security szempontból igazából mindkettő katasztrófális...

Win alatt is nagy mertekben lehet novelni a biztonsagot ha nem Adminisztratorkent hasznlja az ember, es a policy beállításokkal korlátozásokat ir elo.

Igen, bár backdoor/rootkit esetén teljesen mindegy, hogy milyen felhasználóval vagy bejelentkezve. :)

Most viccen és flamen kivül tudsz mondani olyan rendszert amire "ráfoghajtuk" hogy biztonságos, vagy biztonságosabb, mint az összes többi? Széleskörben használt és nem hobby projectről van szó.

--
A nyúl egy igazi jellem. Ott ül a fűben, de akkor sem szívja!

"Ezért szokott security témakörben az első kérdés lenni, hogy kiktől szeretnéd megvédeni a rendszert. Mondjuk az említett emberektől valószínűleg egyébként sem sikerülne."
Ezert nem ertem, miert ne lenne eleg biztonagos kulon patchek nelkul az otthoni gepem. Igaz nem irtam, hogy otthoni geprol van szo, de az ellenkezojet sem.
Kivulrol csak azok a szolgaltatasok erhetoek el, amire szuksegem van.
Van egy router, amibe van tuzfal. A sajat gepemen eleg szigoru tuzfal szabalyok vannak. Frissitem rendszeresen a programokat. Nem telepitgetek fel ossze vissza mindent, nem nyitok meg gyanus leveleket. Csak en hasznalom a gept. ...

Nagyon komolyan erdekel,hogy ilyen korulmenyek kozott is indokolt-e plusz patch a kernelhez.

Nézd végig a 2.6os kernelszéria "biztonsági történelmét".. különös tekintettel az exploitok megjelenési "sebességére".

És ezek "CSAK" a publikus hibák.

Mindazonáltal a 2.6.18.x (3?)as széria óta kb. dec. közepe talán azért nyugi van ezen a téren. Talán előszőr fordul elő hogy megél ez a kernelszéria 1 hónapot sec. probléma nélkül.

/...journal korrupciós hiba nem sec probléma ugye... ;-).../

De a grsec-ben levő TPE jelentősége, hogy pl. megakadályozza hogy mezei userek külső programokat vigyenek bele a rendszerbe. a megbízhatatlan csoportba tartozó userek tulajdonában levő programok nem lesznek futtathatóak. (pl. letöltött, vagy fordított cuccos). És ez csak az egyik ficsőr. /theoretical expamle, hogy hunger röhöghessen ;-) / Nem nyújt tökéletes, és általános védelmet, ezt nem mondtam, de megnehezíti az ártalmas kódok bejutását.

Vagy a szigorúbb chroot() kezelés, stb.

--------

Nem a zsömle kicsi, a pofátok nagy...

Mert a hivatalos irány az SELinux tudtommal. Szóval attól kell várni majd a szent grált. Mellesleg inkább ne tegyenek bele se SELinux-ot, se GRSec-et. Kinek ez kell, kinek az. Én speciel ki nem állhatom a GRSec-et.
--
% make love
Make: Don't know how to make love. Stop.

Nem áll kézre, nekem merev az idea, ahogy Brad elképzelte ennek a beállítását. Hiányzik a policy inheritance meg polymorphism. Egyszóval az SELinux RBAC/MAC rendszere közelebb áll az objektumorientált szemlélethez és ettől nekem nagyon kényelmessé válik. Lehet hogy másnak, aki nem programozott, vagy nem szeret programozni :) ez pont akadály. De ezért létezhet többféle elképzelés is egy problémára.
(Ja, PaX-ot használok)
--
% make love
Make: Don't know how to make love. Stop.

És mi az a "bizonyos körök" ? tökrészeg összeesküvéselméletgyártók ? ;-)

Legalább valami nagyon minimális alapjuk lenne akkor, ha SELinux nem nyílt forráskódú jószág lenne... ;-)

Így azért elég érdekes backdoort elhelyezni benne.

Nem is tudom hány éves a SElinux... > 5 ?

------

Nem a zsömle kicsi, a pofátok nagy...

Jaj tényleg, mindig elfelejtem, hogy a nyílt forráskódú szoftverekben nem lehetnek backdoorok, hisz azt azonnal megtalálja bárki, mint ahogy a bugokat is... Ne legyél már naív. Az SELinux kódja nem 2 sorból áll, auditálni sem egyszerű a bonyolultsága miatt. Simán elrejthető benne programozási hibának álcázott backdoor, vagy akár valami apró 'design flaw', amely ránézésre nem ismerhető fel, nem is tűnik veszélyesnek, csak épp egy jól kitalált privilégium szerzéshez vezető folyamat első lépése.

De azt írják, hogy SE csak picit túr bele a kernel lelki világába.

Az eredeti SELinux patch a 2.4.3-as kernelhez több mint 650k (közel 27 ezer soros) volt. Az pici?

Szerinted hány összeesküvés elmélet gyártó geek nézte már meg, a kódját eddig?

Legalább annyi, mint ahány paranoid nézte át az olyan suid root programok forrását, mint az X, mégis 3 évig nem vette észre senki, hogy mennyire primitív programozási hibának álcázott backdoor ad alkalmat root szerzésére... Pedig az aztán egy hihetetlen primitív backdoor volt, nem egy komoly állami szervezet által jól megtervezett kiskapu.

Nem értem miért olyan nehéz mindezt elképzelni egy olyan ország nemzetbiztonsági hivataláról, amelyik a mai napig korlátozza az államokon kívüli kriptográfiai kulcsméretet.

Azt tudja valaki, hogy a grsec-et miert nem teszik bele a kernel main line-ba, hogy ne keljen patch-cselni (szarakodni) allandoan ?

Hát ez elég hosszú story. Röviden arról van szó, hogy Linus nem akar ilyen hardening cuccokat látni a saját forrásfájában. Egyrészről amikor megjelentek az első ilyen patchek (pl. az első PaX verziók vagy a Solar Designer Openwall/Owl kernel patche, amelyik non-exec stack megoldást kínált), akkor azok még elég gyerek cipőben jártak és könnyen kijátszhatók voltak. Innentől kezdve pedig Linus úgy nyilatkozott, hogy ezek a megoldások alkalmatlanok bármiféle védelemre, mert az exploitok könnyen átírhatók úgy, hogy működjenek ilyen hardened kernelek alatt is. Azóta eltelt ~7 év és a PaX meglehetősen jól kiforrott lett és garantált védelmet ad a támadások _bizonyos_ fajtáira. Ennek ellenére Linus nem változtatta meg a véleményét, így az idő közben elkészült Ingo féle ExecShield is csak a RedHat forrásában szerepel (ráadásul PaX-hoz képest jóval gyengébb és a kijátszásához vannak remek megoldások). Ezeken kívül a grsec tartalmaz még RBAC-ot, amely elvileg kiváltható az SELinux segítségével, viszont utóbbinál jóval nehezebb megvalósítani bizonyos korlátozásokat. A többi megoldásra (chroot hardening, tmp race prevention és a kernellel kapcsolatos védelmek, mint a randomizált és nonexec kernel stack, etc.) meg nem tudom mi a hivatalos válasz, de biztos tudnak rá pár vicces választ adni a nagy Linux developerek. Az új PaX user ptr. deref. és hasonló védelemhez pedig először be kellene látniuk a fejlesztőknek, hogy a tűzoltás jellegű megoldások nem kifizetődők ebben a szakmában...

Mondjuk azért én még emlékszem az ominózis PaX VMA mirroring sebezhetőségre, amikor a sors fintoraként a PaX maga adott alkalmat a rendszeren priv szint emelésre, és ami után PaxTeam a visszavonulsást is fontolgatta (ha emlékezetem nem csal). Szóval kicsit visszás amikor pont az a megoldás hoz hibát a rendszerbe, aminek a feladata a sebezhetőség kihasználásának megakadályozása lenne.

--
trey @ gépház

Yep, sajnos ez így van, de alapvetően a PaX jelenleg azt a célt szolgálja, hogy puffer túlcsordulással kapcsolatos hibákat _távolról_ lehetetlenné tegye (vagy legalábbis olyan mértékben megnehezítse, hogy ne legyen könnyű ezen bugok kihasználása). Amíg meg a vanilla Linux kernelhez tucat számra léteznek 0day local exploitok, addig igazából nem sokat számít, hogy a PaX maga mit ad hozzá (ellenben legalább a remote exploitok ellen megfelelő védelmet nyújt). Ennek ellenére nyilván a következő lépés a lokális bugok kihasználásának megakadályozása lesz (PaX future doksi tárgyalja is ;), de ez jóval nehezebb feladat és egyelőre erre még senki más sem tudott kész megoldást mutatni.

Egyébként a PaX VMA buggal kapcsolatban a mentségére legyen mondva, hogy nem más találta meg, hanem ő és ha nem lenne ilyen lelkiismeretes, akkor gond nélkül javíthatta volna fű alatt úgy, ahogy sok más fejlesztő teszi FOSS és nem-FOSS körökben...

( willy v | 2007. 01. 13., szo – 09:54 )

Lehet hogy FUD, csak az a kerdes miert hagy maganak csak 6 honapos idot arra, hogy a hazugsaga kideruljon? Szted ezalatt meggazdagodik? Ja ebben a szakmaban fontos a bizalom.

fene tudja. lehet fizettek 80E-t az exploitért, és a secusok már többet tudnak ? ;-))

végül is solution is van ;-)))

A PaX-ban viszont secu szerint nincs meg a hiba... ;-))

http://secunia.com/product/3452/?task=advisories

most tegyen az user igazságot ;-)))

----------

Nem a zsömle kicsi, a pofátok nagy...