WebGL Security and Microsoft Bullshit

HUP cikkturkáló

"It’s frustrating to see how bad Microsoft can really be. I’m one of Microsoft’s biggest fans. I still think Windows7 is better than OSX or Linux(*). I play more XBox 360 games than any other console. I was hopeful for Win7 Phone and am hopeful for Windows 8. I was on Microsoft’s side in the Java lawsuit, the Internet Explorer lawsuit and several others. I think Visual Studio’s debugger is way better than anything I’ve used on OSX or Linux. I think C# is way more awesome than Java. I was really happy when they started IE9 development and started actually competing."

http://games.greggman.com/game/webgl-security-and-microsoft-bullshit/

( FeriX v | 2011. 06. 22., sze – 22:45 )

A cikk nem erről a copy paste-ről szól.

( uid_15426 | 2011. 06. 23., cs – 11:07 )

"I think you can see, with all this validation, the odds that a webpage can exercise a bug in a driver become vanishingly small."

Hehehe.

----------------------
while (!sleep) sheep++;

( handler | 2011. 06. 23., cs – 12:20 )

Tekintve a driverek minoseget, es robosztussagat (ebbol a szempontbol a win7+ tenyleg jobban all, ott user modban futnak a grafikus meghajtoprogramok), tenyleg nem hianyzik neki a web :D De nem is lesz robosztus, amig nem lesznek rakenyszeritve a gyartok hogy az legyen...

A google fejlesztett webgl->directx translatort chrome-ba:
http://blog.chromium.org/2010/03/introducing-angle-project.html

a win7+ tenyleg jobban all, ott user modban futnak a grafikus meghajtoprogramok

Dehogy, csak néhány kiegészítő része fut user módban, a fő video driver továbbra is kerneltérben helyezkedik el.

A google fejlesztett webgl->directx translatort chrome-ba

Na ez mondjuk jó ötlet... Gondolom nem véletlenül találták ki Google-nél se, így kicsit biztonságosabbá tehető az egész. ;)

A doksiban epp ellenkezojet emlegetik az aranyoknak - mondjuk kivancsi lennek ati/nvidia/intel implementacioknal mennyi fut kernel modban es mennyi user modban.

"At a technical level, WDDM display drivers have two components, a kernel mode driver (KMD) that is very streamlined, and a user-mode driver that does most of the intense computations. With this model, most of the code is moved out of kernel mode. That is, the kernel mode piece is now solely responsible for lower-level functionality and the user mode piece takes on heavier functionality such as facilitating the translation from higher-level API constructs to direct GPU commands while maintaining application compatibility. This greatly reduces the chance of a fatal blue screen and most graphics driver-related problems result in at worst one application being affected. "

Itt irogattak/rajzolgattak is ati driverrol, az opengl es a direct3d driver usermodban fut:

http://www.elitebastards.com/index.php?option=com_content&task=view&id=…

A directx translator inkabb a hw gyartok trehanysaga - egy eve meg eleg keves gyarto szallitott gles-t a driverekhez. Sot, sokszor semmilyen ogl icd sem volt elerheto, kulonosen regi gepeknel. Vegulis miert irogatnanak 3+ eves kartyakhoz uj drivert? Abbol nincs penz...

Egy olyan kiélezett üzleti versenyben, mint pl AMD vs NVIDIA, _nyilván_ ott csalogatnak kerneltérbe számítást, ahol csak lehet. Te nem ezt tennéd? Én tuti nem hagynék ki egy ilyen ziccert, ha minden bitnyi gyorsulás számítana.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( Hunger | 2011. 06. 23., cs – 21:35 )

Jó a Social Engineering az elején amit beidéztél, kár hogy ettől még butaságokat írt.

Én is írhatnék szép bevezetőt, hogy:

1.) Se a Googlenek, se a Microsoftnak, se más multinak nem dolgozom 

(vele ellentétben)

2.) Bármit amit mondok a munkáltatóm véleményét is képviselheti, tekintve hogy biztonsági kérdésekben az én szavamra hallgatnak 

(vele ellentétben)

Én vagyok a Google egyik legnagyobb rajongója. Továbbra is úgy gondolom, hogy a Linux jobb, mint az OSX vagy a Windows(*). Bizakodó voltam az Android kapcsán és bizakodok a következő ChromeOS-ben. A Google oldalán álltam a Viacom perben, az Oracle perben és még sok másikban. Szerintem a Gmail jobb ingyenes webmail, mint bármi más, amit használtam. Szerintem a Chrome sokkal nagyszerűbb, mint az Internet Explorer. Nagyon örültem, amikor elkezdődött a Chrome fejlesztése és versengeni kezdett a Firefox-szal.

stb. de inkább nézzük a tényeket:

> Microsoft has never supported OpenGL which is what WebGL is based on. Instead they have their DirectX API. The DirectX API is great but the #1 reason Microsoft doesn’t want to support anything based on OpenGL is that it robs them of some of their lock-in.

Ezzel teljes mértékben egyetértek.
Egészen bizonyos, hogy a Microsoft politikai céloktól - is - vezérelve mond ellent a WebGL-nek.

Ellenben nem árt észben tartani, hogy a megfelelő politikai manővereket csak valós alapokra helyezett kommunikációval lehet hatásosan elérni.

Azaz attól mert az MS elsődleges indoka politikai jellegű, még nem jelenti azt, hogy az alapvetően politikai célokra felhasznált IT biztonsági probléma csak mondvacsinált hazugság.

Tehát nem érv a WebGL biztonsága _mellett_, hogy a Microsoft csak azért támadja a WebGL-t, mert az nem DirectX-es...

Pont ellenkezőleg. A veszély nagyon is valós, ezért is próbál most a Mozilla és a Google célt érni azzal, hogy a Microsoftot megpróbálja ellehetetleníteni azzal a boszorkányüldözéssel, amely arra hivatkozik, hogy mivel az MS céljai nem teljesen tiszták, ezért a mondanivalója is eleve hazugság.

A valóság ellenben nem ennyire fekete és fehér...

> So, Is WebGL a security risk? IMO no more than any other part of the browser. Remember when IE had issues with specially formed JPG images? That was a bug. It was fixed. Problem solved. Remember when IE had issues with specially formed AVI files? That was a bug. It was fixed. Problem solved.

Úgy tűnik egyrészről, hogy ez a "security bugs to be just normal bugs" fertőző és ész nélkül veszik át Linus Torvaldstól ezt az ostobaságot a fejlesztők. Számára - és egyes burokba zárt fejlesztőknek - lehet, hogy a sebezhetőségek is csupán egyszerű programozási hibák, de a világ többi részén ez elég komoly fejfájást és dollármilliárdokban mérhető veszteséget termelő problémát jelent...

Másrészről a Fejlesztő Úr aranyosan összemossa a 'user space' biztonsági hibákat a 'kernel space' sebezhetőségekkel. Ez különösen aranyos pont egy Chrome fejlesztőtől, aki egy másik bekezdésben erősen ecseteli, hogy a WebGL azért lesz biztonságos, mert külön processzben fut a weblap:

> So what does Chrome do to keep WebGL safe? #1, like everything in Chrome, we run the webpage in its own process.

Sajnos hiába fut külön processzben a weblap, homokozóban, megfeszítve, mágiával körbezárva, ráolvasva, töviskoronával a fején, bilincsben... a kihasznált biztonsági hiba nem a sandboxolt 'user space' böngésző alkalmazásban (vagy komponensében) van, hanem egy privilegizált driver kódjában a kernel memóriaterületén, amelyre nem lesz érvényes semmiféle korlátozás.

Ezért is irtó veszélyes átadni a WebGL utasításokat ellenőrzés nélkül a videokártya OpenGL interfacének. Természetesen nem is teszik ezt meg, legalábbis a Chrome fejlesztő szerint:

> The other is that the GPU process validates EVERYTHING!!!! before calling the GPU drivers

Amiket azonban felsorol - mint validáció - csak néhány ismert hiba "workaround"-ja és nem pedig prevenciós céllal tervezett proaktív biztonsági megoldások...

Erre viszonylag egyszerű példa lehet a korábban posztolt Proof-of-Concept WebGL kód, amelytől a kezdetektől elhasal az nVidia és az AMD/ATI driver mind Firefox, mind Chrome böngészők alatt a mai napig.

> Silverlight 5, that provides the EXACT SAME FEATURES with all the same issues

Ez a kijelentés több szempontból sem igaz:

1. A Silverlight nem az OpenGL interfacét használja (ezt egy másik - korábbi - kijelentésében ő is elismeri, így ezt az állítását eleve önmaga cáfolja: DirectX for Silverlight). A DirectX-et a Microsoft fejleszti, az OpenGL interfacet viszont közvetlenül a video driver fejlesztői "biztosítják", amely közel sincs biztonsági szempontból annyira auditálva és körbejárva, mint a DirectX.

2. A Silverlight nem önmagában adja át az alacsony-szintű utasításokat a video drivernek, hanem van egy wrappere, amely feldolgozza a kéréseket és a megfelelőnek ítélt hívásokat adja át a DirectX-nek, amely további ellenőrzéseket végez, mielőtt továbbítaná a video drivernek. (Ellenben a WebGL esetében, amely az egészet nélkülözve a video driver OpenGL interfacenek adja át közvetlenül a hívásokat)

3. A Silverlight egy extra plugin, amely külön épül be - vagy nem épül be - a böngészőbe. A WebGL-t azonban alap funkciónak szánja a Google és a Mozilla és a jelenlegi verzióikban már alapértelmezetten bekapcsolva is található, veszélybe sodorva ezzel a felhasználóikat.

> So what do you do to prevent programs from accessing bugs in drivers? Well, #1 is you test your code and try to make sure it’s bug free.

A drága Chrome fejlesztő itt is csúsztat és összemossa a 'user space' security bugokat a 'kernel space' sebezhetőségekkel. Míg a böngészőt érintő biztonsági problémáknál ő - és az MS - felelősséget tud vállalni a hibákért, tesztelni és javítani tudja azokat, addig a WebGL interfacen át kihasznált video driver hibákat nem tudja azonos szinten feltárni és képtelen közvetlenül nyomást gyakorolni a fejlesztőire (hisz azok más cég - nVidia, AMD - alkalmazottai).

Jó példa erre az AMD/ATI video driver, amelyben köztudottan olyan biztonsági hiba van, amely a Microsoft EMET (Enhanced Mitigation Experience Toolkit) teljes védelmi funkciójának kihasználásakor (ASLR AlwaysOn) kékhalált okoz. Ez a probléma ugyan köztudott hónapok óta, még sincs javítva a mi napig az AMD/ATI video drivereiben...

(*) Lehet, hogy nem jobb minden szempontból, de még mindig inkább tartom biztonságosabbnak grsecurity/PaX és további third-party patchek felhasználása esetén, mint a Windows-t vagy az OSX-et.

Ui.: Tudom, hogy az 'olvasók' jórésze egy egyszerű "tl;dr" hozzáállással fogja honorálni a leírtakat, de legalább nagyjából öszeszedtem a jelenlegi WebGL-el kapcsolatos problémákat. A továbbiakban többet nem kívánok vele foglalkozni és rá időt pazarolni...

"2. A Silverlight nem önmagában adja át az alacsony-szintű utasításokat a video drivernek, hanem van egy wrappere, amely feldolgozza a kéréseket és a megfelelőnek ítélt hívásokat adja át a DirectX-nek, amely további ellenőrzéseket végez, mielőtt továbbítaná a video drivernek. (Ellenben a WebGL esetében, amely az egészet nélkülözve a video driver OpenGL interfacenek adja át közvetlenül a hívásokat)
"
vs.
Chrome WebGL: "The other is that the GPU process validates EVERYTHING!!!! before calling the GPU drivers."

Ha ujra elmondod, attol meg nem lesz igaz.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Értem én, hogy egy Google alkalmazott szava mindig igazabb (főleg ha saját fejlesztését kell dicsérnie), de linkeltem példának okáért egy PoC-t, amelyik az EVERYTHING-VALIDATE [BLINK] [BLINK] [BLINK] ellenére omlasztja össze a video drivert, mint a huzat, Chrome alatt is.

Másrészről mi lenne ha megnéznéd a forráskódot, elvégre a Chromiumé szabadon elérhető. Máskor nagy mellénnyel vagy hogy csak kódot kell olvasni, most mi tart vissza, hogy ellenőrízd mit validálnak és hogyan?

Attól pedig nagyvonalúan eltekintek, hogy eleve hülyeség a kijelentés, mert nem lehet mindent validálni. Ha lehetne, akkor NIPS eszközök is minden támadást megfognának és a statikus kódellenőrzők is megtalálnának minden programozási hibát. Ergo nem léteznének azok a problémák, amikről most eleve beszélünk...

A hozzászólásaid egy részében olyan dolog ellen érvelsz, amit senki nem állított. Mindenki tudja, hogy a webgl új kockázatokat hoz. A chrome-os csak azt állítja, hogy az MS véleményével szemben nem a Silverlight a válasz mindenre.

A PoC-hoz annyit, hogy a DoS támadások kiszűrése nem egyszerű, ellenben a kivédésükkel. Azért, mert ami az egyik 8 éves videókártyának DoS művelet, azt egy mai láblógatva megcsinálja 100ms alatt. Ez a javascriptel is így van, a mai napig lehet olyan DoS-t írni, ami 10mp-re megfagyasztja a brózerablakot (chrome) vagy az egész brózert (firefox) - csak aztán a brózer megálljt parancsol és megkérdezi, hogy akarod-e folytatni a futtatását. Szóval ugyanezzel a lendülettel a JS eltávolítása is indokolt. Nálam a PoCodtól 10mp-re beakad a desktop, aztán minden folytatódik, semmi se fagy ki vagy áll le (Fedora 15, Chromium, GeForce 9500 GT, blob driver, kompozit WM).

Igazából a Silverlight melletti kardoskodást nem értem:

> 1. A Silverlight nem az OpenGL interfacét használja (ezt egy másik - korábbi - kijelentésében ő is elismeri, így ezt az állítását eleve önmaga cáfolja: DirectX for Silverlight). A DirectX-et a Microsoft fejleszti, az OpenGL interfacet viszont közvetlenül a video driver fejlesztői "biztosítják", amely közel sincs biztonsági szempontból annyira auditálva és körbejárva, mint a DirectX.

Szóval DirectX egy wrapper a driver körül, épp úgy ahogy pl a Gallium3D is, vagy a Chrome webgl processze. Van arra bármi bizonyíték, hogy a DirectX olyan szűrést végez ami meg tud akadályozni valós driver támadásokat? Szerintem a DirectX sem arra készült, semmi garancia arra, hogy extra biztonságot ad, nem pedig csak a látszatát. Az, hogy dobáljuk a layereket egymásra, még nem feltétlenül biztonság.

> 2. Ellenben a WebGL esetében, amely az egészet nélkülözve a video driver OpenGL interfacenek adja át közvetlenül a hívásokat

Ez esetleg a Chrome böngészőre igaz, a webgl nem ad át semmit semminek. A Chrome nyilván nem tud mindent validálni, ahogy a Silverlight sem.

> 3. A Silverlight egy extra plugin, amely külön épül be - vagy nem épül be - a böngészőbe. A WebGL-t azonban alap funkciónak szánja a Google és a Mozilla és a jelenlegi verzióikban már alapértelmezetten bekapcsolva is található, veszélybe sodorva ezzel a felhasználóikat.

Hm, épp az előbb írtad valakinek, hogy a webgl-t a firefox nightly build-ekben kézzel kell bekapcsolni. Ez amúgy sem jó érv, nyilván a 99%-os penetrációra hajt a Silverlight is. Ez épp olyan, mint amikor azt állítja valaki, hogy a Linux biztonságos, mert senki nem használja, ezért nincs rá vírus sem. Gondolom te sem tartozol abba a táborba.

A DirectX épp úgy a gyártók drivereitől függ, mint az OpenGL. Ha a driver bugos, itt is, ott is a gyártónak kell javítania. Ha a gyártó nem javítja, akkor a workaround lehetséges itt is, ott is.
Úgy írsz néha a DirectX-ről, mintha az nem lenne kiszolgáltva hardware drivereknek, a webgl-ről pedig úgy, mintha nem lenne lehetséges minden utasítás szűrése. Az, hogy jelenleg nem szűr eléggé a Chrome, a Chrome hibája, nem a webgl-é. Más kérdés, hogy jelenleg tudtommal nincsenek tipikus webgl támadások, így egyelőre nincs tapasztalat arról, hogy mit is kell kiszűrni, de nem lehet mondani, hogy nem próbálkoznak.

Egyetértek veled abban, hogy a webgl para, csak abban nem, hogy a flash/silverlight jobban tudja csinálni, sőt. Emlékszem még, amikor napokig vagy hetekig kellett kritikus flash sebezhetőséggel kellett szántani a webet, mert épp úgy értek rá Adobenál.

Ó bakker, írtam, hogy nem akarok a továbbiakban ezzel foglalkozni, de annyi baromságot hordtál össze, hogy kénytelen vagyok rájuk válaszolni...

A hozzászólásaid egy részében olyan dolog ellen érvelsz, amit senki nem állított.

LOL? Ha nem tűnt volna fel, akkor beidéztem az eredeti mondatokat, amik ellen érveltem.

Mindenki tudja, hogy a webgl új kockázatokat hoz.

Hatalmas tévedés. A felhasználók jórésze nem tudja. A legtöbb azt se tudja mi az a WebGL, mégis alapértelmezetten bekapcsolásra került a böngészőjükben, veszélynek kitéve őket.

A chrome-os csak azt állítja, hogy az MS véleményével szemben nem a Silverlight a válasz mindenre

Te itt valamit nagyon félreolvastál, mert az MS sehol se írta, hogy a Silverlight a válasz mindenre.

Szóval ugyanezzel a lendülettel a JS eltávolítása is indokolt

Biztos, hogy elolvastad amiket írtam? Egyrészről hatalmas csúsztatás összemosni egy JS végtelen ciklus miatt belassuló böngészőt, egy teljes desktop merevre fagyást okozó video driver buggal... Másrészről külön kiemeltem, hogy a DoS itt a legkisebb probléma.

Igazából a Silverlight melletti kardoskodást nem értem

Te tényleg valamit nagyon félreolvastál. Itt nincs semmiféle Silverlight melletti kardoskodás. A Silverlight csupán egy példa, hogy meglehet ezt jobban és biztonságosabban is csinálni. Senki sem javasolta a Silverlightot a WebGL helyett.

Szóval DirectX egy wrapper a driver körül

Hát ennél a DirectX egy picivel több. :)

Szerintem a DirectX sem arra készült, semmi garancia arra, hogy extra biztonságot ad, nem pedig csak a látszatát

Tekintve, hogy a DirectX több komponensét is használják már sok éve (Direct2D, DirectInput, DirectSound, DirectX Video Acceleration, stb.) a webes kiegészítők (mint pl. az Adobe Flash, vagy az Adobe Shockwave) és még sose használtak ki rajta keresztül video driver hibát, ezért mindegy, hogy szerinted a DirectX sem arra készült... Amit fel kellene fogni, hogy a DirectX egy külön absztrakciós réteg, míg a WebGL az magának a video drivernek az OpenGL interfacével beszélget, ami viszont mindig is katasztrófális volt biztonság szempontjából. Konkrétan annál valóban sose volt szempont a biztonsága.

Nem is véletlen, hogy a Google is nézelődik inkább abba az irányba, hogy Windowson legalább a DirectX-en keresztül hívja meg az OpenGL ES2.0 API-kat.

A Chrome nyilván nem tud mindent validálni, ahogy a Silverlight sem

Tehát mégegyszer: a Silverlight ellenben nem a video driver OpenGL interfacével beszélget direktben.

Hm, épp az előbb írtad valakinek, hogy a webgl-t a firefox nightly build-ekben kézzel kell bekapcsolni.

Igen, a nightly buildekben, ott is csak kb. 1 hete. A stabil változatokban továbbra is alapértelmezetten be van kapcsolva. Nyilván a Mozillánál is rájöttek időközben, hogy elég veszélyes ez így és most a fejlesztői ágban már nincs alapból bekapcsolva. Remélhetőleg a következő nagyobb verzióváltásnál már a userek jórésze által használt stabil változatban is a kikapcsolt lesz a default.

Ez amúgy sem jó érv, nyilván a 99%-os penetrációra hajt a Silverlight is.

És? Hol az összefüggés? A Silverlight nem része egyik böngészőnek sem alapértelemezetten, külön kell telepítenie a felhasználónak. Anélkül nem veszélyeztetheti a usert, ellenben a WebGL-el, amely szépen le lett nyomva userek torkán, a tudtuk nélkül.

Ez épp olyan, mint amikor azt állítja valaki, hogy a Linux biztonságos, mert senki nem használja, ezért nincs rá vírus sem.

Ugyan itt se látom az összefüggést, de amit leírtál így van. 1% desktop Linuxra nem éri meg botnetet építeni.

Gondolom te sem tartozol abba a táborba.

Ez nem tábor kérdése, hanem az objektív gondolkodásé.

A DirectX épp úgy a gyártók drivereitől függ, mint az OpenGL.

Csak az előbbit jópár nagyságrenddel többen használják. OpenGL annyira halott, hogy jópár driver nem is tartalmazza. Ez a másik indok, amiért a Google is a DirectX-en keresztül használná inkább a WebGL-t.

Ha a driver bugos, itt is, ott is a gyártónak kell javítania.

Persze, csak egy rakás hiba van, amely DirectX-en keresztül nem triggerelhető, OpenGL interfacen keresztül meg igen. Ráadásul a DirectX-en keresztül sokkal inkább tesztelik, mert jobbára mindenki azt használja már több mint 10 éve.

Ha a gyártó nem javítja, akkor a workaround lehetséges itt is, ott is.

A DirectX ad egy stabil, független layert amit használnak, ami adott esetben jópár video driver problémát eltakar. Ez biztonsági szempontból jó, ha DirectX-en keresztül érhetők csak el a funkciók, viszont ha a DirectX-et megkerülik - mint WebGL esetében -, akkor egy mozdulattal borul az egész kártyapakli. Azért is írtam, hogy eddig is probléma volt, mert lokálisan kihasználhatók voltak eddig is a video driverek hibái, viszont így egy mozdulattal távolról is kihasználhatóvá tették...

Úgy írsz néha a DirectX-ről, mintha az nem lenne kiszolgáltva hardware drivereknek

Tehát mégegyszer: az a driver ami DirectX-en keresztül kapásból észrevehető problémákat okoz előbb kibukik, hisz minden QA erre van ráállva. Mindenki DirectX-en keresztül tesztel, benchmarkol Windows platformon manapság már.

Arról nem is beszélve, hogy az Xbox-nál is.

a webgl-ről pedig úgy, mintha nem lenne lehetséges minden utasítás szűrése.

Lehetni lehetséges, a probléma pont abban volt, hogy ez még elég kezdetleges, ha egyáltalán van...
Firefox fejlesztői ágba most került be nem rég egyáltalán egy alap shader validator, eddig nem is létezett.

Az, hogy jelenleg nem szűr eléggé a Chrome, a Chrome hibája, nem a webgl-é

Ez már megint a specifikáció vs. implementáció kérdéskör, amin turul16 is rugózott. Olvasd el ott erre mit írtam, nem akarom újra leírni.

Más kérdés, hogy jelenleg tudtommal nincsenek tipikus webgl támadások

Persze, gondolom még most ocsudnak fel az IT seces emberek a csodálkozásból és köpni-nyelni nem tudnak.

így egyelőre nincs tapasztalat arról, hogy mit is kell kiszűrni

Jah, de azért ki lett rakva pármillió ember veszélynek, a default WebGL-el.

Egyébként ezt is írtam turul16-nak. Előbb fel kellett volna tárni a WebGL miatt megjelenő új veszélyforrásokat, meg kellett volna érteni a feltártakat és a specifikációban rögzíteni az elkerülésükhöz szükséges alapokat. Nem pedig utólag fejet vakarni és implementálgatni ilyen-olyan szűrőket, hogy azok majd talán megoldják a problémát. Agyrém.

de nem lehet mondani, hogy nem próbálkoznak.

Jah, eső után köpönyeg.

Emlékszem még, amikor napokig vagy hetekig kellett kritikus flash sebezhetőséggel kellett szántani a webet

Apple vs. Oranges. A flash úgy szar ahogy van, de legalább nem egylépésben lehetett rajta keresztül támadni a kernelt, mint jelenleg a WebGL-nél.

Ez a vita parttalan. Állandóan webgl-t emlegetsz, holott csak a windows implementációját kritizálod, amihez a webgl szabványnak nem sok köze. Pl az, hogy az OpenGL-t teljes mértékben a video driverek implementálják, csak Windowsra igaz, nem minden webgl megjelenítésre alkalmas platformon van így. Mellesleg ott lesz a Chrome, ami -mint mondod- tudja majd a DirectX backendet, szóval én nem is értem, hogy miről vitatkozol tulajdonképpen. Azt látom, hogy minden kiragadott mondatra van egy cáfolatod, csak épp a témára nincs. (Talán turul se értene félre, ha jól használnád a fogalmakat és azt írnád, amire gondolsz.)

> Te itt valamit nagyon félreolvastál, mert az MS sehol se írta, hogy a Silverlight a válasz mindenre.
Nem támogatja, sőt, kritizálja a webgl-t a biztonsági hiányosságai miatt, ellenben a Silverlight5-ben teljes mellbedobással a 3D mellett van. Tehát az szerintük biztonságos .. vagy hazudnak, hiteltelenek.

> Egyrészről hatalmas csúsztatás összemosni egy JS végtelen ciklus miatt belassuló böngészőt, egy teljes desktop merevre fagyást okozó video driver buggal
Erre már most van megoldás a webgl-be. A PoC-od egyszerűen nem működik. Az nem DoS, hogy 10mp-re megakad a gépem HA megnézem az oldalad. Én értem, hogy ezzel akarod szemléltetni, hogy mi mindent be lehet adni a GPU-nak amitől fejreáll (egyet is értek vele!), de azt akarom látni, hogy:

  • a DirectX ezt minden esetben out-of-box megakadályozza
  • webgl-ben képtelenség rá megoldást találni

Ha ezek nem teljesülnek, akkor nincs miről vitatkozni, mert abban egyetértünk, hogy a webgl extra kockázat, ami eddig nem volt. De mutass jobbat, követendőt - a Silverlightos érveid egyelőre nem tudom elfogadni.

> Tekintve, hogy a DirectX több komponensét is használják már sok éve (Direct2D, DirectInput, DirectSound, DirectX Video Acceleration, stb.) a webes kiegészítők (mint pl. az Adobe Flash, vagy az Adobe Shockwave) és még sose használtak ki rajta keresztül video driver hibát, ezért mindegy, hogy szerinted a DirectX sem arra készült... Amit fel kellene fogni, hogy a DirectX egy külön absztrakciós réteg [...] (- igen, jelenleg, WINDOWS-on.)
Az Adobe Flash nem MS platformon pedig OpenGL-t használ épp azóta, amióta Windowson DirectX-et. - most jön megint az, hogy de Windowst sokan használnak..?

A Chrome inkább azért nézegeti a DirectX-et, hogy minél több, régebbi hardverrel is kompatibilis legyen, ahogy te is írtad. A többit talán csak te képzeled bele.

  • Tehát mégegyszer: a Silverlight ellenben nem a video driver OpenGL interfacével beszélget direktben.
  • Persze, csak egy rakás hiba van, amely DirectX-en keresztül nem triggerelhető, OpenGL interfacen keresztül meg igen.
  • A DirectX ad egy stabil, független layert amit használnak, ami adott esetben jópár video driver problémát eltakar.
  • Mindenki DirectX-en keresztül tesztel, benchmarkol Windows platformon manapság már.

Továbbra is megválaszolatlan a kérdésem, hogy hol a bizonyíték arra, hogy a DirectX valós támadást képes kiszűrni? Az, hogy sok game van rá, semmit nem jelent. A Linux kernel is rengeteg szoftvert futtat a világban, aztán mégis kibuknak benne több éves hibák is amikor valaki jól ránéz.
Pl Linuxon a Gallium3D egy csomó duplikált kódot kivesz a driverekből, akárcsak a DirectX. Hogy windowson ez nem így van, ahhoz csak a böngészőknek van némi köze, de semmiképp nem a szabvány alkotóinak.

>>Ez épp olyan, mint amikor azt állítja valaki, hogy a Linux biztonságos, mert senki nem használja, ezért nincs rá vírus sem.
>Ugyan itt se látom az összefüggést, de amit leírtál így van. 1% desktop Linuxra nem éri meg botnetet építeni.
Attól nem lesz biztonságos, követendő példa, csak kevésbé kockázatos használni.

>Egyébként ezt is írtam turul16-nak. Előbb fel kellett volna tárni a WebGL miatt megjelenő új veszélyforrásokat, meg kellett volna érteni a feltártakat és a specifikációban rögzíteni az elkerülésükhöz szükséges alapokat. Nem pedig utólag fejet vakarni és implementálgatni ilyen-olyan szűrőket, hogy azok majd talán megoldják a problémát. Agyrém.
Feltárták. Azért jött létre pl a GL_ARB_robustness, azért van a Chromiumban watchdog, ami leállítja a PoCod 10mp után. Szerintem megtették azt ami elvárható, eddig nem is láttunk értékelhető exploitot, csak a szájtépést. Persze biztos vagyok abban, hogy egyszer lesz, de az, hogy eddig még nincs, holott 2 major browser by default sebezhető lenne vele vele, az akár azt is jelentheti, hogy felkészültek..

>>de nem lehet mondani, hogy nem próbálkoznak.
>Jah, eső után köpönyeg.
Nézted, hogy mikori spec.? Jóval régebbi, minthogy az első aggályok publikusan megjelentek..

Az, hogy by default be van kapcsolva, tényleg necces. Legalább egy kérdést feldobhatna, hogy a weblap ilyen olyan hozzáférést kér a géphez, ami kockázattal jár. Ez a kérdés azonban teljesen független a webgl-től, sőt, nem is igazán műszaki kérdés, nem is onnan kell megközelíteni.

http://www.contextis.co.uk/resources/blog/webgl2/
ez elég egyértelmű.POc az csak tesztelésre van.Lényegesen több van abban.
Amit leírsz az kb az hogy windows hány százalékos desktop os és hány százalék linux-unix-egyéb.Szal részben mind1 ha directx csak elfedi a hibákat ha ezt úgy teszi hogy nincs rá POC magyarul akár azt is hiheted hogy majdnem 99%százalékosan biztonságos.AMit nem tudsz az nem fáj,és ha nincs mit kihasználni mint hiba akkor biztonságban érezheted magad.

A fő gondom az nekem, hogy nem látom bebizonyítva, hogy a DirectX valóban elfedi a hibákat. A DirectX nem egy security layer ami erre garanciát vállalna. Ennek ellenére emberek jönnek és megmondják, hogy a webgl by design sz*r, mert nem köti ki, hogy DirectX kell alá*, bezzeg a Silverlight. Nyilván vannak és lesznek hiányosságai, nagyon fiatal API, de nagyon korai kijelenteni, hogy alapjaiban van elcseszve, mert nem.

Egyébként a brózerekben újra és újra felbukkannak sebezhetőségek, webgl nélkül is. Sad, sad world..

* sarcasm

nem látom bebizonyítva, hogy a DirectX valóban elfedi a hibákat.

Nem kell hogy bebizonyítva legyen. A Silverlight és DirectX biztonsági hibákat jóval egyszerűbb javítani, mint a WebGL biztonsági hibáit. Ez az, amit viszont nem kell bizonyítani se, mert egyértelmű.

Olyan biztonsági szakértők értenek ebben egyet, mint Dan Kaminsky.

Egyébként a brózerekben újra és újra felbukkannak sebezhetőségek, webgl nélkül is

Ugyanakkora ostobaságokat beszélsz, mint a Google alkalmazott és összemosod a dolgokat. A böngésző user space applikáció, a WebGL pedig közvetlen kernel space támadási felületet hozott létre, amely mostantól távolról is támadható. PONT

Nyilván jóval egyszerűbb lesz javítani, hiszen kereken 1 implementáción fog működni. :) Ez csakis az MS-nek előny, ebben nem összehasonlítható a webgl-el.

Jelenleg egy távoli kódfuttatási hiba a brózeremben azt jelenti, hogy simán lenyúlják a bankból a pénzem. Hol érdekel engem utána, hogy a kernelbe nem jutottak be. Ha majd meg lesz oldva, hogy a brózerben megnyitott egyes lapok teljesen elszeparált környezetben fussanak egymástól és a rendszertől, akkor ráérünk amiatt pálcát törni a webgl fölött, hogy megkönnyíti a kijutást (bőven van ideje akkorra kiheverni a gyermekbetegségeit - sajnos). Szóval lesz*rom a kernelt, PONT. :)

Mondjuk a handler által linkelt doksiban mintha a GL épp full userspace "interpreter" lenne.

Nyilván jóval egyszerűbb lesz javítani, hiszen kereken 1 implementáción fog működni.

Nem, azért lesz egyszerűbb javítani, mert nem három külön vendorral kell egyeztetni a javítást illetően, hanem az MS megoldja házon belül. És ők nagyságrenddel jobban értenek a biztonsági témákhoz, mint az nVidia vagy az AMD/ATI.

Ez csakis az MS-nek előny, ebben nem összehasonlítható a webgl-el.

Ez leginkább a felhasználóknak előny. WebGL esetén legjobb esetben a Google/Mozilla próbálkozhat workaroundolni a problémát, amit vagy sikerül rendesen megoldani, vagy nem.

Enterprise szinten mindenesetre nem kérdés, hogy melyik vállalhatóbb, a Microsoft hivatalos javítása, vagy a Google/Mozilla workaroundja.

Jelenleg egy távoli kódfuttatási hiba a brózeremben azt jelenti, hogy simán lenyúlják a bankból a pénzem.

Chrome-nál és IE9-nél ennél például egy kicsit bonyolultabb a helyzet, de valóban nem 100%-os a szeparáció. Ha viszont arra vársz, hogy az legyen, akkor nyugodtan várhatsz még jódarabig...

Állandóan webgl-t emlegetsz, holott csak a windows implementációját kritizálod

Igen? Jó tudni.

Én nem csak a Windows implementációját kritizáltam. Mindenhol ugyanúgy problémás a jelenlegi megoldás, csak Windowson könnyebb lett volna jobbra megcsinálni. HTH

amihez a webgl szabványnak nem sok köze

Nem szabvány, specifikáció és van hozzá köze, ahogy már leírtam. Nem fogom magamat ismételni.

Pl az, hogy az OpenGL-t teljes mértékben a video driverek implementálják, csak Windowsra igaz

Nem, nem csak Windowsra igaz.

Mellesleg ott lesz a Chrome, ami -mint mondod- tudja majd a DirectX backendet, szóval én nem is értem, hogy miről vitatkozol tulajdonképpen

Én nem vitatkozom semmiről, én tényeket közöltem. Aki vitatkozni próbál az te vagy... :)

Azt látom, hogy minden kiragadott mondatra van egy cáfolatod, csak épp a témára nincs.

LOL? Aki össze-vissza beszél az te vagy.

Talán turul se értene félre, ha jól használnád a fogalmakat

Kemény szavak ezek attól aki "WebGL szabványt" emleget. ;)

Nem támogatja, sőt, kritizálja a webgl-t a biztonsági hiányosságai miatt

A jelenlegi formában elfogadhatatlan, így nem támogatja. Teljesen jogosan.

A legnagyobb OpenGL támogató fejlesztő, aki talán a legkomolyabb dolgokat hozta ki az OpenGL-ből anno szintén egyetért a Microsofttal. Úgy hívják, hogy John Carmack, talán már hallottál róla...

Úgyhogy itt zárjuk le. Nincs kedvem, se időm ilyen faszságokon vitatkozni, amikor a helyzet egyértelmű.

Ha valami "megfelel a specifikációnak", akkor a magyar sokszor mondja rá, röviden, hogy "szabványos". My shame, de én a köznyelvben ebből kifolyólag szinonímaként használom ezeket. Nyilván rossz körökben mozgok, megpróbálok majd kitörni, de addig sok ilyen lesz még, majd bebindelem a szót hotkey-re (hupkeyre) és úgy írom, hogy szabvány. :)

Nem tudom, amit látok az az, hogy a gyártók erősen trükköznek a video drivereikkel...

Eleve nem is értem hogyan tud például kékhalállal elszállni az ATI driver, ha be van kapcsolva AlwaysOn-ra a _userspace_ ASLR. Max. arra tudok gondolni, hogy az ASLR miatt elszáll a userspace komponens és emiatt a kernel-oldal is csődöt mond. Már települ a WinDbg, mert legalább MiniDumpom van a problémáról, amivel ellehet kezdeni kideríteni, de elsőre annyi látszott, mintha rossz memóriacímre hivatkozna a kernel driver.

Kékhalállal szállt el akkor is, amikor a PoC-t meglátogatva megfagyott 1 percre a desktop, majd utána próbálta volna újraindítani a drivert (a Windows kernel) és nem sikerült neki. Ha itt csak simán a userland részt kellene újrainicializálni, akkor nem lenne ilyen szerintem...

mondjuk a nightlyban nekem még (tegnap) a webgl be volt kapcsolva, csak valamiért balcklistelve volt a webgl (vga driver inkompatibilitás elviekben) ezt a blacklistet overrideolta a webgl force enabled flag. Tehát __még mindig default__ be volt kapcsolva a webgl, csak nálam nem.