Root exploit pro ovladač grafických karet NVIDIA

bez toho bulvarizacneho stylu by to neslo ? :-((

Mně to nevadí. Já bych byl dokonce ještě tvrdší. Mnohem tvrdší. NVidia o tomto problému totiž ví už od 7. července a dodnes to neopravila (viz zpráva o exploitu).

Software bez chyb asi neexistuje, s tím je nutno se smířit.
Horší je ovšem přístup nVidie, vědět o chybě a neopravit ji je hodně drsné.
Osobně to beru tak - jenom kvůli tomu hardware měnit nebudu, ale při koupi dalšího si dám echt pozor, aby tam tento problém nebyl.

To zní rozumně. A mohl bys dát tip na nějakou grafickou kartu, co je rozumně výkonná, dobře fungující v Linuxu a přitom nemá ten zlý binární ovladač?

Intel onboad grafiky?

Klasicky problem uzavreneho modelu vyvoje - u opensource projektu by se naslo dostatecne mnozstvi lidi, kteri by chybu opravili v nejkratsim moznem case. (BTW zatim pouzivam binarni fglrx, ale postupne prechazim na xorg drivery kde se da).

To se dalo tusit, jednou se splete kazdy. Ale na serverch to nemam tak co oni to urcite opravi. A pouzivat se to nemusi.

Přesně tak, na server si nikdo nvidia ovladače nedává, protože tam nejsou potřeba. Když už tam někdo potřebuje GUI, tak určitě ne s 3D akcelerací ;).
A co se týká desktopu, tak si myslím, že i s touto chybkou je to pořád bezpečnější, než widle ;).

oops.

jeste ze mam ati - ta nikoho nezajima, tak na ni nebude psat ani root exploit ;-)

no... tak takove reakce mimo misu jsem necekal :) problem neni v tom, jestli nvidia dela pozde bugfixy, ale problem je prave v typu ovladace - tj. blob, closed source driver bezici pod privilegovanym uzivatelem!!!

co je dnes pro nvidia, muze byt casem pro kazdy blob :)

No jistě. U FOSS jsou chyby opravovány rychle, může je najít a opravit kdokoliv. U uzavřeného softwaru nikoliv. Takže v podstatě stačí použít binární ovladač typu nVidia a těchto výhod FOSS se člověk zbavuje. A ona prodleva, o které jsem psal výše, to potvrzuje. Chyba není opravena ani po třech měsících. Kdyby byly ovladače FOSS, mohla být už 7. července.

U uzavřených aplikací mi to tolik nevadí, ty běží v userspace, takže moc škody nenapáchají. Ale binárka v kernelspace mi přijde jako zvěrstvo. Pro mne je důsledek jasný, jakmile objevím jinou možnost, skočím po ní. A do té doby nebudu šetřit kritikou.

Hmm a co ked problem je model pristupovych prav v Linuxe a nie v driveri ?

1. X bezi pod rootom afaik, to je prvy zaklad uspechu.
2. pax ? vieme ze X ma s tym problem aby bezal na non-execute stacku (aspon mal ked som to skusal)

Cize sice je pekne ze vsetci teraz kricia "Hovorili sme to !!!" ale napravu by mali hladat inde a nie v driveri od Nvidie.

Blob je prasárna ať už si vykřičíš plíce nebo ne.

Takže v binárce od nVidie je zjištěna buffer overflow zranitelnost, ale chyba je na straně přístupových práv v Linuxu? To se mi nějak nezdá. Možná, že jiný bezpečnostní model či některá opatření by vám třeba mohla pomoci, aby tato chyba nekompromitovala systém, ale i tak by to byla chyba, a to na straně nVidie. Váš pohled mi připadá stejně absurdní, jako říkat, že prasácky napsaný web je vlastně chyba na straně prohlížeče, který má chyby očekávat a pokoušet se za autora domýšlet, jak to vlastně myslel.

Prezrite si reakcie v tomto threade nizsie.

Otazka je: Budem kricat na binarny driver ktory je zle napisany, ze ma buffer overflow dieru, alebo implementujem mechanizmy ktore znemoznia buffer overflow diery vyuzivat do kernelu ?

Ak budem len kricat tak to mozem robit stale a nice sa nezmeni, programatori su tiez len ludia a robia chyby.

Alebo spravim dobry privilege separation mechanizmus a som v pohode proti HOCIJAKEMU chybnemu driveru (ci uz closed alebo open source).

No jestli vam to stoji za to, zkuste HURD. Zatim maji ale mikrojadra velke problemy s efektivitou. Krome toho, dokud zustaneme u architektury PC, tak stejne cokoliv co muze na sbernici (tedy ma primy pristup na hardware) dokaze pocitac hacknout ...

Problem je i v architekture X Window. Ale nemusi bezet pod rootem, na openbsd je beh X Windows privilege separated. Na openbsd treba pod rootem bezi uplne minimum. A nyni X Windows vyuziva aperture driver, ale i tak ma primy pristup k hardware... Proto se pracuje na framebuffer wscons/X, aby Xka nemely primy pristup k hw a nemusely vubec mit takova privilegie, ale za cenu ztraty ficur grafickych karet :(

Chce to nove Xka, zalozene na bezpecnosti. Dle nejakych plku u openbsd developeru, nynejsi vyvojaru Xorg moc na tuto kritiku neslysi.

A to jak pracuji X Windows pod linuxem... - neni se cemu divit :))

Nieco na "bezpecnosti" Xorg na linuxe bude - ale na druhej strane, driver potrebuje mat priamy pristup k HW portom karty. Tj. bud by muselo byt povolene userspace driverom sahat na urcite porty, co je z hladiska bezpecnosti prasarna, alebo pouzit iny mechanizmus.

Co si pamatam o x86, tak existovali "brany volani" a u TSS bitmapa "neprivilegovanych portov", cim by sa dalo driver schovat do neprivilegovaneho segmentu (napr. s CPL 1, aj tak neni vyuzity) a vyuzivat driver volanim jeho sluzieb (tj. driver by mal pristup na rozsah portov napr. 0x3a0-0x3ff). Len jednak to prepinanie je strasne pomale (skor deceleracia nez akceleracia) a jednak to neni moc prenositelne na ine architektury.

Njn, ked tak este zapnut ASLR.

uplne stejne by jsi mohl do userspace mmapovat i memory space daneho zarizeni...

By vlastne stacilo ioperm(), driver by potom zhodil root privileges via setuid() a pouzival inb()/outb(). Samotny kernel driver by len spristupnil video RAM nejak cez mmap, aby userspace cast drivera nemusela zapisovat do /dev/mem.

Pokud se nepletu, tak každá moderní grafická karta v sobě obsahuje DMA engine pro přenosy dat z a do karty aby tam člověk nemusel všechno přenášet ručně. Pak už jen stačí kreativně naprogramovat vhodný DMA přenos a jsem kdekoliv si jen budu přát. Ano můžete driveru zakázat přímé šahání na portu té videokarty a řešit to nějakým tím syscallem který si nejprve zverifikuje zda neděláte něco divokého ale následky pro výkon té grafiky budou fatální.

Obavam sa, ze DMA bude fungovat na prenos do video RAM, ale HW porty su "iny adresny priestor", tj. DMA rozhodne zrychli prenosy RAM <-> video RAM, ale prinicipielne nevyriesi prava pristupu k HW portom. Na druhej strane je pravda, ze s "direct HW" programovanim som skoncil pri SVGA kartach s LFB (potom ma to uz nejak prestalo bavit), takze sa rad poucim, ak mate presnejsie info (tj. co sa da prenasat via DMA, co sa nastavuje via HW porty atd.).

Už si nepamatuji kde jsem to četl ale byla to reakce jednoho vývojáře xorg který komentoval proč se nesnaží pomoci *BSD s jejich snahou provozovat xserver jako obyčejný uživatel. Víceméně řekl, že každá moderní grafická karta má DMA engine který umí poslat cokoliv kamkoliv (t.j. čtení jak z operační paměti tak i zápis do ní).

1) video driver MUSÍ mít přímý přístup k portům jinak bude zoufale pomalý
2) jakmile má přístup k portům, tak si pomocí DMA šáhne kamkoliv do paměti
3) pokud program může kamkoliv do paměti, tak je efektivně root

Takže snažit se provozovat video driver tak aby neběžel jako root je zbytečná práce.
Resp. půjde to pro nějaký ten VESA driver ale grafika pak bude nutně neakcelerovaná.

Vsechno spravne az na to, ze 3 ve skutecnosti znamena vic nez root: neexistuje zadne vyssi opravneni nez primy zapis do libovolne adresy pameti, zatimco muzete byt root a porad mit neco zakazane (ruzne ty vylepsene chroot/jail to delaji).

Neni to jen otazka videokaret. Dneska maji podobne schopnosti i radice disku, sitove karty, zvukove karty ...

bugy v ruznych, zvlast na desktopovych zarizenich, jsou, byly i budou. Neni treba z toho delat kdovijakou udalost jenom proto, ze jsou ty ovladace binarni...

Projdete si LKML a podivejte se, kolik ruznych bugu (i vic ci mene exploitovatelnych) v ruznych driverech bylo objeveno..

To, ze nvidia tyhle chyby opravuje pozde, je samozrejme chyba, ale na druhou stranu, budme radi za funkcni a rychle ovladace. Kdo nechce, nemusi je pouzivat. Ale jsou tu i lide, co rychlou a hlavne funkcni 3D akceleraci (opensource DRI ovladace, co jsem mel tu cest vyzkouset, povetsinou nesplnuji ani jedno) potrebuji k praci(a tim opravdu nemyslim hrani Q3A).

A doufat v uvolneni tehle driveru pod nejakou opensource licenci je pomerne naivni, vzhledem k soucasnym pretekum mezi ATI a NVIDIi.

Snad mám jako zákazník právo přinejmenším vyjádřit svou nespokojenost. Nebo se nám pokoušíte naznačit, abychom "drželi ústa a krok"?

"A doufat v uvolneni tehle driveru pod nejakou opensource licenci je pomerne naivni, vzhledem k soucasnym pretekum mezi ATI a NVIDIi."

IMO by to byla naopak dost silna zbran vedouci k prevaze, protoze by samozrejme vyvoj ovladacu zacal jit rychleji (kdyz by se zapojila komunita) a tudiz by linux uzivatele zacali preferovat tu znacku.

Co jsem ale slysel, tak problem je, ze ATI a nVidia sama nemuze rozhodnout, jestli uvolnit ovladace nebo ne, protoze ty jejich ovladace vyuzivaji technologie nekoho dalsiho a k nim nemaji prava na zverejneni/otevreni.

Podarilo se nekomu ten exploit uspesne rozchodit? U sebe na masine jsem ucinil vse jak bylo popsano ale root priviledges nejak ne ne prijit. Haze po mne errorem. Zeby bug v exploitu? ;)