A nemrég napvilágra került "local root" Linux kernel sebezhetőség javítása az Ubuntu repókban

Ubuntu

2008. február 10-én itt a HUP-on megjelent írásból is értesülhettünk, hogy olyan exploit forog közkézen, mellyel az újabb Linux kerneleket futtató disztribúciókon helyi felhasználóként root jogot lehet szerezni (CVE-2008-0010 és CVE-2008-0009).
A nem hivatalos patch-ekről már a cikkben is olvashattunk. Tegnap azonban megjelent a hivatalos Ubuntu tárolókban a 2.6.22-es kernel javított változata (2.6.22-14.52), melyben ez a biztonsági hiba javításra került. 


TESZT@AMD:~/kernel exploit$ gcc jessica_biel_naked_in_my_bed.c
TESZT@AMD:~/kernel exploit$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7e2b000 .. 0xb7e5d000
[-] vmsplice: Bad address
TESZT@AMD:~/kernel exploit$  

TESZT@AMD:~/kernel exploit$ apt-cache showpkg linux-image-2.6.22-14-generic
Package: linux-image-2.6.22-14-generic
Versions:
2.6.22-14.52
...

Érdemes frissíteni mindenkinek!

( pepo v | 2008. 02. 13., sze – 08:30 )

Felteszem, ez a javítás már megjelent más diszrtibekhez is, érdemes mindenkinek szétnéznie.
Az Ubuntu tárolókról letölthető nemcsak a javított natív Kernel, hanem a header, továbbá a Kernel forrás is.

( traktor | 2008. 02. 13., sze – 18:09 )

Debian Etch-ben mar 10-en delutan meg volt a javitas (legalabbis a changelog szerint, aztan hogy az a tukorszerverekre mikor er ki azt nemtom).

( pepo v | 2008. 02. 13., sze – 21:34 )

Elmondhatjuk, hogy gyorsan reagált a Linux világa a hiba kijavítására.
Most vagy azért, mert futótűzként terjedt, vagy azért, mert fajsúlyos a hiba, vagy mindkettő, de mindenesetre dicséretes a disztribútorok reagálása.
Pár éve olvastam egy MS reklámcikkben, hogy az MS hibajavítási reakcióideje felülmúlja a Linux-okét. (Talán 3 disztribbel hasonlították össze az XP-t.)
Na, erre varrjon gombot Ballmer!

Itt nem ez a probléma... Lényegében, ha Jonathan Corbet (leginkább LWN szerkesztő/vezető, nem pedig kernel developer) kiváncsiságból nem kezdi el nézegetni, hogy hogyan is működik pontosan az exploit (amit úgy tűnik a főállású kernel fejlesztők nem tettek meg), akkor a látszólagos hibajavítás miatt, mindenki szépen hátradőlt volna, hogy minden rendben van és csak a blackhatek röhögtek volna szokás szerint, hogy a qaaz által ravaszul megírt exploit mögött egy teljesen más hiba kihasználása áll.

Szóval amit csináltak egy tüneti kezelés volt és hihetetlen nagy mázlinak lehet csupán csak nevezni, hogy egy elsősorban nem kernel fejlesztőként tevékenykedő tag ennek alaposabban utánajárt és rájött a valódi probléma forrására...

Én nem habzok, hogy ha ezt rám értetted...

Ez az exploit egyébként elég sok mindent elindított. Szintén vicces felfedezés volt, hogy a kernel configban beállítható CONFIG_CC_STACKPROTECTOR lényegében semmit se ért ezidáig, mert a Makefile-ban felül lett bírálva egy gcc paraméterrel (-fno-stack-protector), így sose került a kernelbe a stack smash védelem.

A poén tovább fokozódott, amikor PaXTeam leírta, hogy a gcc-ben lévő stack protector láthatólag akkor sem adja hozzá a védelmet a kernelhez, ha a Makefile javításra kerül, valamint hogy a szintén kernelben található CONFIG_CC_STACKPROTECTOR_ALL opciót valószínűleg az életben sem próbálta ki senki, ugyanis ezzel lefordítva a kernelt már bootkor elszáll az egész...

a gcc-ben lévő stack protector láthatólag akkor sem adja hozzá a védelmet a kernelhez, a szintén kernelben található CONFIG_CC_STACKPROTECTOR_ALL opciót valószínűleg az életben sem próbálta ki senki, ugyanis ezzel lefordítva a kernelt már bootkor elszáll az egész...

Esetleg lehet hogy kipróbálták, és ezért bírálták felül a makefile ben ? :-)

Nagyon sok félkész kód van a kernelben szvsz. Én pl. az "acpi kódok" között találtam pár hónapja hasonlókat. ott "#define *acpi_akarmi" cimmel, kár hogy az adott acpi_akarmi a kernelben sosem került kiválasztásra. Az ilyenek többségét ellátták "future" jellegű kommentekkel, de volt amit nem. :-)

Az olyanokról már nem is beszélve, hogy ha egy "fájlt" egy architektúra alatt nem tudnak lefordítani, és hackolnak olyat néha, hogy akkor azon az arch-on nem fordítják le. :-)

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

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

Az, hogy közfelháborodás után kiadnak egy-egy ilyet, az még engem, Windows szerver admint nem vigasztal, hogy vidám kis hibák garmadáját csak a patch kedden javítják. Nemtom, hogy belenéztél-e már miket szoktak ott foltozni. Itt napok óta lovagolunk egy local root-on, amikor ennél sokkal súlyosabb remote problémákkal kell nap mint nap megküzdeni a rendszereken.

--
trey @ gépház

Az eredeti állítás ettől még továbbra sem igaz, ezzel együtt nem áll szándékomban védeni a Microsoft security update policy-jét, csak annyira humoros, hogy minden ilyen hírben azonnal előjon a "bezzegaM$"-kényszerbetegség.
It doesn't matter if you like my song as long as you can hear me sing

Eszem ágában sincs elterelni. Sőt. Rendkívül jó, hogy ekkora figyelmet kap. Azt hiszem, hogy pont nekem és a HUP-nak köszönhető, hogy ez itthon ekkora figyelmet kap. Még akkor is ha egyesek rendszeresen rápróbálkoznak ennek az ellenkezőjének bizonyítására. Itt valamit te benézel. Ha a HUP nem lenne, akkor még mindig a blogodban beszélgetnél a Google botokkal a linugz problémáról. Próbálj valami komolyabbat.

--
trey @ gépház

Fogalmam sincs, ki próbálkozik rá, hogy mi köszönhető az oldalnak és mi nem, és megvallom őszintén, nem izgat senkinek a bármivel kapcsolatos ePenis-e, egyszerűen csak értetlennek találtam, hogyan került ebbe a hírbe az MS.
It doesn't matter if you like my song as long as you can hear me sing

( xray | 2008. 02. 15., p – 19:12 )

Sziasztok!

Nem akartam emiatt külön topikat létrehozni ezért ide írok.
Milyen védekezési módszert javasoltok az ehhez hasonló local exploitok ellen?
chrootolt userek? A környezet megépítése elég körülményes.
Valami speckó kernel amit jobban lehet biztonságilag finomhangolni pl grsec, lids (többet sajnos ilyet nem ismerek:( )?
Esetleg valami egyéb dolog?

De ha sokan válaszolnak akár nyithatok topicot is :-)

Öngyilkos akarsz lenni vagy csak pusztán a jó kedvedet akarod lelohasztani itt? Ha előrébb olvastál volna, nem tettél volna fel ilyen kérdést mert leordítanak.

De én válaszolok: Ez egy csak helyi terminalból kihasználható sebezhetőség. Ez ellen - ha nem foltozol - azzal tudsz védekezni hogy rajtad kívül senkinek nem engedélyezed a konzol elérését.

"Milyen védekezési módszert javasoltok az ehhez hasonló local exploitok ellen?"
- Nem osztogatsz fűnek-fának shell accesst ("adjal akkountot" ugye)
- a php/perl/python/anyámkínnya webserveres szolgáltatásnál letiltod a külső binárist meghívó függvényt (alap lenne amúgy is)
- körülnézel az egyéb szolgáltatásaid közt, hol tudnak még külsősök "hozott anyagból dolgozni", és ezt szintén megakadályozod
(nagyon remélem hogy ez a felsorolás senkinek sem mond újat.................)