"Linux 2.6.31 perf_counter 0day Local Root Exploit"

 ( trey | 2009. szeptember 17., csütörtök - 15:22 )

A Grsecurity mögött álló Brad Spengler (spender) egy videót tett közzé a tegnap, amelyen az látható, hogy egy 2.6.31-es kernelen root jogokhoz jut:

A mellékelt infók szerint egy "kernel crash"-ként leírt bugot használ ki. Az exploit egyelőre nem publikus és a közzétételkor csak x86-on működött. Információk szerint spender "megcsinalja meg x64-re is, aztan publikalja".

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

spender meg mindig "ott van"!

És még vicces is. :D

:D

nemtom de ezzel a 2.6.31-el valami nagyon nem koser... felraktam tegnap egy uj szerverre, es random dobalta el a processzeket signal 11-el (mar boot kozben is, init-et pl). 2.6.30 meg tokeletesen mukodik. (hardversen okes a gep, le volt tesztelve, ecc-s ramok stb, de 2.6.30 alatt a kernel forditas stb is megy tokeletesen).

sajnos hataridos melo volt, nem volt idom kikiserletezni hogy mi a halal baja van az uj kernelnek... pedig nagyon erdekelne

A'rpi

ha megirod, hogy lehet reprodukalni kb (kernel config, userland disztro, progik, stb), akkor ranezek ("ki tudja, megint mit dugtak el a changelog-ban" alapon ;).

Egy tok alap slackware telepites volt, az meg mukodott rendesen. Utana forgattam ra uj kernelt (2.6.31) es reboot, eloszor nem talalta az init-et (pedig ott volt), akkor reboot regi kernellel, megneztem hogya z fs rendben van, ujra reboot uj kernelbe, na akkor bootolt de kiontott vagy 10 oldalnyi signal 11-et (getty-tol kezdve kb minden elhalt ami boot scriptekben/inittabban van) aztan a vege az lett hogy az init nem talalt tobb processzt es halt.
Ezutan vissza boot regit (slackware 13 gyari kernele), forditottam egy 2.6.30-at (a 2.6.31-bol atmasolt .config-al!) es az mukodik azota is.

Sajnos a gepet mar nem erem el, de semmi extra nem volt a .configban, csak a szokasos alap dolgok, a driverek amik kellettek a gephez, meg netfilter stb.

A'rpi

milyen verziók affected? gondolom nem csak 2.6.31, hanem korábbiak is...

de, csak 2.6.31, -rc1-től.

Kész az exploit x64 portja, elérhető az enlightenment-ben, a kernel exploit frameworkben.

Valaki nézze már meg korábbi kerneleken.

minek? írtam fennt, hogy 2.6.31-rc1-be került be a hibás kód a 0793a61d committal.

az egesz perf_counter mizeria is nemreg kezdodott, ha jol emlekszem, nem? (FIXME erosen azert:)

Lehet tevedek, de a problema alapja itt is a maszatolas volt.

---
pontscho / fresh!mindworkz

Bar ez csak workaround, de annyira nem lehet az a selinux olyan jol belove, mert nalam, a user home-jabol nem futtathat semmit:

[xguest@cella ~]$ id -Z
xguest_u:xguest_r:xguest_t
[xguest@cella ~]$ echo echo hi > 22
[xguest@cella ~]$ chmod +x 22
[xguest@cella ~]$ ./22
bash: ./22: Permission denied

Persze, nagy esz nem kell ezt "megkerulni":

[xguest@cella ~]$ sh 22
hi

Nem is a megkerulese a lenyeg, hanem az, hogy nem a default beallitasa van ezekszerint, igy meg lehet mar kukacoskodni is.

Szerk: Beneztem, user_t-re nincs futtatasi tiltas a home-ra, csak a guest_t-nek. A fenti igy nem igaz.

Felemás érzésem van ezekkel az exploitokkal kapcsolatban. Legalább 10 éve programozok, de még sosem írtam egyetlen olyan programot sem, ami a stack-en futott volna. A program a kódlapokon fut, a stack meg adatot tárol.

El tudja magyarázni nekem valaki, hogy az operációs rendszer miért nem lövi ki a fenébe a programot, ha a stack-területen kezd futni?

A kódlap nem írható, az adatlap nem futtatható, azaz nincs puffertúlcsordulásos exploit.

Aki meg olyan programot ír, hogy a következő utasítás = előző + 3, azt támogatás helyett dutyiba kellene zárni.

Nem stack-en fut a kód. Olyasmi a lényeg, hogy a kernel stack-en túlcsordulás miatt át tudja írni a visszatérési címet egy userlandbeli kód címére, ahova meg azt tölt be előtte amit csak akar.

Ez ellen valszeg szegmentálással lehetne védekezni, némi teljesítményromlás mellet, ha támogatja az architektura, de gondolom amiatt hogy nem csak egy arch-on fut a kernel, ezt nem valósították meg. Többek közt az x86_64-ekbe már nem is támogatja a proci.

Persze el lehet képzelni mindenféle protector-cookie-kat meg hasonlókat. Ha jól tudom a kernel heap-re terveznek hasonló megoldást. Meg talán a gcc-ben is van stack-protector opció, bár kérdés hogy maga a kernel lefordítható-e azzal. Persze itt azért gondolom az is játszik, hogy minden plusz biztonsági megoldás ront a rendszer teljesítményén.

Az utolsó mondatra meg: épp az amd64-ben hozták vissza a relatív ugrásokat :-)

A szegmentalasra, memoriavedelemre, futasvedelemre joreszt megoldast nyujt a PaxTeam patch-e. Jo lenne, ha bekerulne a mianline-ba, ha mar a fel vilag hasznalja az otleteit.

Köszi a választ.

Nem relatív ugrásról beszéltem, hanem a kód byte értékének átírásáról. MOV EAX,EBX-ből MOV EAX,ECX-et csinálsz.

Arra gondolsz, hogy pusztán a stack átírásával is lehet programozni?
(ez gyakrolatilag függvényhívásoknak egymásutánjának felel meg)

[Stack teteje]
fuggveny1( par1, par2 );
fuggveny2( par3, par4, par5 );
ugras a rosszindulatu kodra

fuggveny1 mondjuk letolti a kodot
fuggveny2 csinal vele valamit
utána ráugrik

Sem fuggveny1, sem fuggveny2 nem rosszindulatú önmagában, csak rosszra használják (pl memcpy, ...).

Igen, de jelen esetben a fuggveny1() egy teljesen saját függvény, amivel olyan kódot hajt végre az ember, amilyet akar... ;)