Távoli és helyi "root" kódfuttatásra alkalmat adó hiba az NVIDIA bináris linuxos meghajtóiban

Bug

A Rapid7 egyik új biztonsági figyelmeztetőjében arról számol be, hogy helyileg és távolról egyaránt kihasználható, súlyos (puffer túlcsordulásos) hiba van az NVIDIA zárt forrású, Linux-alapú operációs rendszerekhez használható eszközmeghajtó-programjában. A hibát sikeresen kihasználva a rosszindulatú támadó parancsokat hajthat végre a sebezhető rendszeren a "root" felhasználó nevében.

A biztosan sebezhető diverek a v8774-es és a v8762-es verziójúak. Emellett a figyelmeztető kitér arra is, hogy elképzelhető, hogy az NVIDIA FreeBSD-hez és Solaris-hoz használható driverei is érintettek. Az sem zárható ki, hogy a korábbi verziójú driverek is sebezhetőek.

Frissítés: Itt azt állítják, hogy a hiba már javítva van az 1.0-9xxx driverekben.

A hiba jelenleg nincs javítva. A hibáról többen is említést tettek már az NVNews fórumban, és máshol is. Van olyan jelentés ami 2004-ben datálódik. Az NVIDIA 2006. július 7-én erősítette meg először publikusan a bug jelenlétét. Az NVIDIA ígéretet tett a javításra. A hibajegy szerint a legutolsó NVIDIA driver is érintett a hibában. Arról nem szól a bejelentés, hogy a napokban kiadott 1.0-9xxx sorozatú driver is érintett lenne, de mivel a driver kiadásakor nem hívta fel a cég a figyelmet arra, hogy súlyos biztonsági hibát javított volna, feltételezhető, hogy igen.

A bejelentés szerint a hiba javításáig a megoldás az lehet, hogy a bináris driver helyett használjunk nyílt forrású "nv" drivert.

A hibajegy mellé a bejelentő egy PoC exploitot is mellékelt.

A hibajegy itt.

( Toma_ | 2006. 10. 17., k – 08:51 )

Jól értem, hogy az Xorg is kell neki a futáshoz?
Akkor, ha Xgl fut, működik _ez_ az exploit?
_______________________
Magyar égre, magyar UFO-t!

http://tompik.tvn.hu/ufo.jpg

( turul16 v | 2006. 10. 17., k – 09:16 )

Hogy lesz ebbol tavoli exploit?
Nekem nincs nyitott X portom a net fele, akkor vedve vagyok, ugyeee..

"(via a remote X client or an X client which visits a malicious web page)"

Ezt nem egészen értem. A mellékelt exploit egy font heap overflow-t használ ki egy ügyesen elkészített ablak létrehozásával. Távoli kódfuttatáshoz az is kell, hogy az a bizonyos malicious web page rávegye a böngészőmet, hogy egy ilyen ablakot hozzon létre. Ezt azért valószínűtlennek tartom.

Javascript azért sok helyen van. Ettől függetlenül nem vagyok biztos benne, hogy amit az nv_exploit.c bemutat azt Javascript-ben is meg lehet csinálni.
Viszont szvsz X verzió függő az exploit, mert a heap overflow az X-ben levő kódterületre ír. Én ezzel egy kicsit megnyugodtam, hogy nem így fogok rootkit-et kapni a gépemre.

( traktor | 2006. 10. 17., k – 09:18 )

Nagy pofon ez a zart drivereknek. Szerencsere...

( Wercsy | 2006. 10. 17., k – 09:23 )

Mi az "alkalmazat adó"? Új adófajta? :-)

( Csigaa | 2006. 10. 17., k – 10:19 )

Rohadtjóóóó...
OS nv driver => XVideo (beépített sw lassítású zoommal) helyett Xshm+zoom, ami kb hasonló eredményt produkál => "opcionlális" CPU upgrade, hogy lehessen fullscreenben filmet nézni TVfelvétel közben? :/

Lehet ideiglenesen visszapakolom a Radeon7000et (unsupported by ATi) a gépbe, az Xorg 7.1 radeon driverével milyenek a tapasztalatok?

( gsimon | 2006. 10. 17., k – 11:18 )

fél-offtopic filozofálgatás:

Most eszembe jutott a közösség hardware bugokra adott hozzáállása. Ugye volt már ilyen, gondoljunk csak az egyes procik 'nem dokumentált' opkódjaira, az ix86-osok unreal módjára, a 16650 soros vezérlő fifo-kezelésére, a pentiumok osztási hibájára, a firewire busmastering külső eszköz által kihasználható teljes memóriaelérésére, és a hasonlókra.
Na ezeket mindenki szépen simán, több-kevesebb morgással elfogadta, és senki sem csattant fel, hogy "bezzeg ha a hw tervezéséhez bárki hozzáférhetne, bárki nekiláthatna javítani" - talán mert tudat alatt azért ott van, hogy ha a vasakat is úgy 'terveznék', ahogy a linux kernelt növesztik, kétnaponta lehetne gépet cserélni. Miért is van ez a különbség, mármint a vas és az azt alacsony szinten hajtó driver ennyire különböző kezelése között?
Gondoljunk csak bele: ha lenne egy platformfüggetlen 'bios' api spec a videokártyákhoz, akkor az nvidia nem drivert adna ki, hanem prom-ba égetve feltenné a kártyára, és kész lenne. Akkor is menne ez a cirmogás, hogy 'zárt forrású tehát a sátán eszköze'? PC-n a bios kódja sincs kint, mégis elég jól elvannak az emberek az acpi-val és társaival. Az intel procik mikrokód-frissítése és az intelligensebb lemezvezérlők firmware-e is zárt, és szintén semmi gondot nem okoz, és ha netán bug van benne, mindenki szép nyugisan megvárja a gyártó frissítését, és nem rágja a szappant a jobb szájhabosítás érdekében.
Persze, látom én a különbséget, miszerint az egyik a vason van tárolva, a másik meg a vinyón, bizonyos esetben az egyiket a vas futtatja, a másikat meg a proci(k), de nem érzem ezt akkora jelentőségűnek, hogy ekkora tájszépészeti szájtépészet legyen körülötte. Bár, mivel az (l)gpl óta tudjuk, hogy a lib linkelése, statikus hozzáfordítása ill. a külső daemonnal való kommunikáció szinte hitelméleti jelentőségű különbségekkel bír, már nem csodálkozok...

( Oscon | 2006. 10. 17., k – 20:17 )

OFF:

ill. félig. lehet ennek köze ahhoz, hogy a PaX legújabb ficsőrjei közül valamelyik talán az első (?) - nem próbáltam le külön külön -

- memory_uderef
- memory_sanitize

valamint az nvidia driver 3D módban fagyasztják a gépet ?
2Dnél nincs gond. 3D-s cuccosnál azonnal K.O. legyen az akár egy 3D-s képernyőkímélő...

(log sincs, kernel panic sincs. merevre fagy a gép)
amennyiben a két funkció kikapcsolva, akkor megy minden.

elvben lehet hogy mondjuk egy nvidia driverben levő "0 point dereference bug" akasztja meg a fenti (PaX-ficsőr)+nvidia 3D kombinációt ?

----------

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

( Aikon | 2006. 10. 17., k – 20:28 )

Arra vagyok kíváncsi, hogyan fog ez megjelenni majd a proghu-n :)