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".
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
spender meg mindig "ott van"!
- A hozzászóláshoz be kell jelentkezni
És még vicces is. :D
- A hozzászóláshoz be kell jelentkezni
:D
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
ha megirod, hogy lehet reprodukalni kb (kernel config, userland disztro, progik, stb), akkor ranezek ("ki tudja, megint mit dugtak el a changelog-ban" alapon ;).
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
milyen verziók affected? gondolom nem csak 2.6.31, hanem korábbiak is...
- A hozzászóláshoz be kell jelentkezni
de, csak 2.6.31, -rc1-től.
- A hozzászóláshoz be kell jelentkezni
Kész az exploit x64 portja, elérhető az enlightenment-ben, a kernel exploit frameworkben.
- A hozzászóláshoz be kell jelentkezni
Valaki nézze már meg korábbi kerneleken.
- A hozzászóláshoz be kell jelentkezni
minek? írtam fennt, hogy 2.6.31-rc1-be került be a hibás kód a 0793a61d committal.
- A hozzászóláshoz be kell jelentkezni
az egesz perf_counter mizeria is nemreg kezdodott, ha jol emlekszem, nem? (FIXME erosen azert:)
- A hozzászóláshoz be kell jelentkezni
Lehet tevedek, de a problema alapja itt is a maszatolas volt.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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, ...).
- A hozzászóláshoz be kell jelentkezni
Igen, de jelen esetben a fuggveny1() egy teljesen saját függvény, amivel olyan kódot hajt végre az ember, amilyet akar... ;)
- A hozzászóláshoz be kell jelentkezni