grsecurity: sorozatos kernelhibák?

Kernel

Brad Spengler (spender) a grsecurity névre hallgató kernelpatch fő fejlesztője a grsecurity 2.1.0 tegnapi bejelentésében 5 komoly, eddig javítatlan Linux kernel biztonsági hibára utalt.

A hibák javításához Brad nem csak a grsec patchet, hanem az általa kiadott egyéb patchek biztonsági javítások alkalmazását is javasolja.

A grsec 2.1.0 bejelentésében Brad azt panaszolja, hogy többször próbáltak kapcsolatba lépni a kernelfejlesztőkkel a hibák javítása miatt, de nem kaptak választ.Az első alkalom tavaly december 15-én volt, mikor Brad jelezte Linusnak az "RLIMIT_MEMLOCK bypass with locked stack" sebezhetőséget. Utána december 27-én a PaX team jelezte a "2.6.9+ mlockall/expand_down DoS by unprivileged users" hibát. Végül 2005. január 2-án a PaX team újra elküldte előző levelét Linus Torvaldsnak és Andrew Mortonnak is.

A levelekben csatolva volt a megfelelő javítás és a PaX team levelében a működő exploit is. Annak ellenére, hogy a kérdéses időszakban Linus és Andrew is commitoltak változtatásokat a kernelbe, választ nem kaptak.

Brad fel van háborodva a dolog miatt, aminek hangot is adott a bejelentésben.

Valaki forward-olta a Brad levelét a Linux listára és választ kért a fejlesztőktől. Andrew Morton válaszában a kövekezőket írta: mivel egy privilégium nélküli felhasználó a halálba tudja DoS-olni a Linux kernelt a malloc-kal és a memset-tel, így a RLIMIT_MEMLOCK bug nem igazán különleges, a többi jelzett bughoz pedig root felhasználó kell. A problémát továbbította a megfelelő embernek, és várható a javítás.

Alan Cox is válaszolt, szerinte az összes javítás benne lesz (az azóta már megjelent -ac7-ben).

akkor olvasd tovabb, mert a thread-nek meg nincs vege ott sem ;-). az 'aktualis alrendszer karbantartoja' egyszeruen nem letezik a MAINTAINERS szerint, az meg a vilag legrohejesebb dolga, hogy ezt a google-bol kelljen kitalalnom (BSD-knel miert futja security-officerre?). Alan Cox pedig explicite nem a security contact, nezd meg magad, helyet a vendor-sec vette at, szep sikerrel, mert mind a do_brk(), mind a uselib() exploitok onnan kerultek ki. szoval koszond meg inkabb, hogy nem oda kuldtuk a levelet, mert akkor minden valamire valo blackhat elotted 2 hettel tudott volna mar rola (mondjuk a uselib-t fuggetlenul az isec-tol mar fel eve felfedeztek, de most nem ez a lenyeg) - akkor meg mindig felelotlen vagyok mert direkt a fofelelosokhoz fordultam? amugy meg tenyleg felmerult, hogy Alan-t is megkeressuk, de sajnos addigra (2 het hiabavalo varakozas utan) kifutottunk az idobol, mert a uselib() napvilagra kerult, a spender is kesz lett az uj grsecurity-vel (amiben benne voltak mar a mi bugfixeink is), nem volt mit tenni, ki kellett adni.

Amiota Linus es Morton az OSDL-nel dolgozik, egyre kevesbe az "egyszeru nep" tamogatasa a feladatuk. Amig Linus hobby programozo volt, addig o is kodolt. Ma mar a nagy cegekkel tartja a kapcsolatot, interjukra valaszol, es a sajat kernelfajat igazgatja. Annak idejen par evvel ezelott letrejott az alrendszer karbantartok intezmenye.

Nekik kell a patcheket elkuldni, majd ok velemenyezik, es ha erdemes vele foglalkozni, akkor elkuldik Linusnak. Ennek egyetlen oka van: ne terheljek vele ot.

A megfelelo ut szerintem az lett volna, ha Andrew Mortonnak kuldi spender a levelet. Mindenki tudja, hogy o a karbantarto. Morton - ha jol ertettem - januar masodikan kapta meg a levelet, es tovabb is kuldte a megfelelo embernek. Ha jo helyre kuldik a levelet, akkor nem kell varni 1 honapot.

Ha olvasod a kernel listat lathatod, hogy Morton szinte mindenkinek valaszol.

>amugy meg tenyleg felmerult, hogy Alan-t is megkeressuk, de sajnos addigra (2 het hiabavalo varakozas utan) kifutottunk az idobol, mert a uselib() napvilagra kerult, a spender is kesz lett az uj grsecurity-vel (amiben benne voltak mar a mi bugfixeink is), nem volt mit tenni, ki kellett adni.

Most mar tudjatok ki az emberetek. Cox ahogy megkapta meg az ejjel (ha jol emlekeszem) megcsinalta a patchet. Sot az egyiket (moxa) at is irtam mert nem volt jo?

Greg Kroah-Hartman lefordított cikkét olvastam erről én is a Linuxvilágban, és nekem ez valahogy baromira nem tetszik. :I

Nagyon megszoktam eddig, hogy amit leszedek az ftp.kernel.org-ról, vagy a tükrökről, az (többé-kevésbé :))) friss, működik és egész stabil. No meg a kurrens lyukak foltozva vannak benne.

Anno volt is belőle flame emlékeim szerint, hogy kaptak a kernel fejlesztők olyan bugreportokat, amiket pl. a Redhat és más disztribek összegányolt kernelei csináltak, nem a stock kernel.org-féle változat. Most meg az az érzésem, hogy a default verzió is sok helyen összegányolt. :I

BTW, ha már Linus szerint a disztribek kiadóinak kéne erre odafigyelni, tud bárki arról is valamit, hogy pl. a Debian fejlesztők ezt csinálják?

Lehet, hogy a Bitkeeper fölgyorsítja a fejlesztést, de azért az nem kéne, hogy a színvonal rovására menjen. :(

Baze. A Hurd :-)), Debian tul lassu, a Linux kernel tul gyors. Hat lehet nektek jot csinalni?

Viccet felreteve:

Allitolag igy lehet a leggyorsabba haladni a fejlesztessel. Az, hogy irtak egy uj utemezot, es az csak 2 ev mulva jelent meg a legfrissebb stabil kernelben az sem volt az igazi. Lehet, hogy nem a legjobb a jelenlegi, de nem hiszem, hogy barmelyikunk is vezetett volna mar ekkora projektet, hogy tudjuk, hogy mi a jo vagy a rossz. A bazari fejlesztes elve: adj ki gyorsan, agyj ki sokszor. Vagy bevalik vagy nem. Majd az ido igazolja vagy cafolja a dontest...

``Annak az alrendszernek nincs karbantartoja,''

Ha nincs alrendszer karbantarto, akkor a fokarbantarto szabaly el. Legalabbis nekem ez a logikus...

``Andrew Morton szakertelmet pedig megkerdojelezi az, hogy nem tud kulonbseget''

Andrew Morton, mint irta tovabbkuldte a megfelelo embernek.

Nyilvan egy ember nem erthet mindenhez. Nem is feladata, hogy ertsen, a lenyeg hogy a munkajat vegezze el jol. Ez jelen esetben a koordinacio.

es mit ad isten, mi is a fokarbantartokat kerestuk meg. eloszor Linus-t (aki mellesleg a karacsony elotti levelezes alapjan berakott egy kisebb info leak fixet a sajat fajaba), aztan Andrew-t is. amikor mar az utobbi sem valaszolt egy hetig es kozben beutott a uselib() krach, na akkor ment ki az uj grsec verzio + advisory-k (a ketto elkerulhetetlenul osszekapcsolodik, mert a grsec-ben mar fixalva voltak a bugok).

( dzsekijo | 2005. 01. 08., szo – 15:19 )

On 2005-01-08, Micskó Gábor <trey@hup.hu> wrote:

> Valaki forward-olta a Brad levelét a Linux listára [3] és választ kért a
> fejleszt?kt?l. Andrew Morton válaszában a kövekez?ket írta [4]: mivel egy
> privilégium nélküli felhasználó a halálba tudja DoS-olni a Linux kernelt a
> malloc-kal és a memset-tel, így a RLIMIT_MEMLOCK bug nem igazán különleges,

Ez vicc. Hogy mondhat ilyet? Az hogy a bug nem top priority abbol nem kene
h. kovetkezzen h. masszivan szarnak ra es a reportot beadora. Betegek ezek a
linux kernelfejlesztok.


( Misi | 2005. 01. 08., szo – 17:43 )

Ha igaz, hogy le se sz@rtak a hibabejelentot, akkor ez nagyon-nagyon rossz fenyt fog vetni a fejlesztokre. Nem adok 1 hetet, s a media arrol irni, h lam a linux kernel fejlesztoi se jobbak, mint az m$ fejlesztoi, ok sem foglalkoznak a biztonsagi hibakkal :((((

Misi

A "mas" operacios rendszer alatt mit ertesz?

Idezzelek a forumbol, hogy hogyan jartal az OpenBSD-vel? Idezzek a sajat bugreportjaim-bol, hogy en hogy jartam mondjuk a FreeBSD fejlesztokkel? Van pelda szamtalan. Vagy mire gondolsz? Ezek szerint nem gondoljak olyan sulyosnak a hibat, mint masok.

A magam reszerol nem szandekozom tulparazni a dolgot, csak eszembe jutott, hogy milyen frankon felfujhato ez a dolog es az milyen jol johet bizonyos embereknek.

Azt nem fogjak gondolom leirni, hogy jo jo, karacsony volt, es 5 nap mulva megvan a fix, meg ilyenek, csak azt, hogy lam, lam megsem valaszolnak a levelekre a fejlesztok, pedig mekkora hibarol/hibakrol van/volt szo.

Misi

Szerintem Brad Spengler gondolta magat akkora ¨valakinek¨, hogy valaszolnak neki....

Ha pl. en irok nekik egy hasonlo levelet, termeszetes, hogy nem valaszolnak :-), ellenben Brad mar letett egy-ket dolgot az asztalra; azert megert volna egy ¨megkaptuk, b.u.e.k., vettuk az adast¨-szeru valaszt.

Ha figyeled az elmult honapokat, akkor lathatod, hogy az isec.pl-es hibajegy utan mindig par (jopar) nappal kesobb jott ki az uj kernel verzio (pre,rc formajaban altalaban).

Pecs elerheto volt hamarabb is, de az most is van...

Amirol most beszelunk meg annyira sem erdekes, mivel nem local/remote root exploitrol van szo.

az en meglatasaim:

1. egyik bug sem egetrengeto fontossagu (nem merheto ossze a uselib() buggal ;-), de ez nem ok arra, hogy le se szarjak az embert 2-3 heten at, unnep ide vagy oda. kerdezd meg thuglife-ot, hogy az OpenBSD fejlesztok mennyit ulnek egy hasonlo szintu kernel bugon. szerintem orakban merheto.

2. az altalam talalt bughoz nem kell uid=0 2.6.9 ota, pont ezert valt security bugga. es Andrew peldajaval ellentetben erre nincs beepitett automatikus ellenszer (malloc/memset eseten ugye belep az OOM killer vagy az overcommit/vm accounting).

szoval rovidre fogva, 'i tested the waters' es nagyon nem tetszik, amit lattam.

Olvastam az LWN.net-en. Bar ott is felvetettek, hogy lehet, hogy ezekkel a bugokkal nem Linus-t vagy Mortont kellett volna keresni, hanem az alrendszer aktualis karbantartojat. Ok mar nem biztos, hogy tudak ilyen problemakkal foglalkozni. Szerintem Alan Cox jobb valasztas lett volna... Hamarabb lehetett volna eredmenyre jutni.

Sajnos ez a par óra nem mindig igaz. Ez nagyon sokmindenen múlik. Csak az a baj, hogy a userek sokszor olyasmiket várnak el ami emberileg is lehetetlen és azt hiszik, hogy a fejlesztők ejjel nappal a gep előtt ülnek és csak ezzel a dologgal foglalkoznak. Az viszont, hogy valaki nem valaszol egy vagy tobbszori emailre az mar bunkóság. Ez ugyan az mintha valakihez hozzaszolsz es nem valaszol.

Nekem ez nem mutat mast mint, hogy az uj fejlesztesi modell szerint megy minden. Linus es Morton folyamatosan fogadjak az uj dolgokat a 2.6-ba, nincs 2.7. Megmondtak korabban, hogy ez azzal jarhat, hogy a vanilla 2.6 nincs mindig a legjobb allapotban. A elmondtak mar tobbszor tobb forumon, hogy _disztributorok feladata_, hogy a kernelen a vegso csiszolasokat elvegezzek. Az egyik ilyen csiszolo Alan Cox, mint a Red Hat kepviseloje. Es ahogy latszik, Alan Cox teszi is a dolgat. Amig Morton egy kernelhez kiad ket patchet ( -mm [www.hup.hu]), addig Alan ( -ac [www.hup.hu]) mar 8-nal tart. Es Alan fajaban az _osszes_ hiba javitva van, amirol tudomast szerez. Igy erdemes ot keresni. Akinek stabil 2.6 kell az hasznalja az -ac fat.

Szerintem.

en nem altalanos bugokra gondoltam, hanem kifejezetten security bugokra. azokon szerintem (remelem ;-) nem ultok heteket, hanem max napokat, es semmikepp nem vartok a visszajelzessel az idok vegezeteig. amugy a 'par ora' sajat tapasztalat, tavaly novemberben bekuldtem egy kisebb (nem security) bugot a tech@-re, 25 perc mulva jott a valasz a javitassal.

itt nem az uj kernel verzio megjeleneserol van szo... spender 3 hete irt levelet a hibakrol a kernelfejlesztoknek es idaig nem voltak hozza patchek, mert senki se foglalkozott vele es a problemakkal. Annyit se mondtak spendernek, hogy mukk. Szoval majdnem 1 honapig _nem volt_ hozza patch es nem is reagaltak a problemakra.

Nem akarok megint flamet, de ha egy ilyen eset jon elo a Windows-nal, akkor az MS mar el van kuldve a pokolba...