Názory k článku
Root exploit pro ovladač grafických karet NVIDIA
-
Shadow (neregistrovaný)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. -
Haplo (neregistrovaný)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. -
Shadow (neregistrovaný)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.
-
Haplo (neregistrovaný)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). -
jirib (neregistrovaný)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 :)) -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)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. -
anonymníCFLAGS=... -fPIC ...
--
CONFIG_GRKERNSEC_PROC_MEMMAP:
If you say Y here, the /proc/<pid>/maps and /proc/<pid>/stat files will give no information about the addresses of its mappings if PaX features that rely on random addresses are enabled on the task.
--
nv_exploit.c:
/* This exploit takes two arguments:
* o The lowest address past X's heap.
* o X's data address.
*/ -
Petr Baláš (neregistrovaný)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í.
-
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)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.).
-
Petr Baláš (neregistrovaný)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 ... -
hx (neregistrovaný)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. -
R/W (neregistrovaný)"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.
ČLÁNKY DO MAILU