Számomra a '90-es évek első naív e-kereskedelmi próbálkozásait idézi fel a WebGL megjelenése. "Milyen jó lenne, ha virtuális 3D-s bevásárlóközpontokat építhetnénk" - mondták (és mondják) néhányan, akikben még nem tudatosult, hogy jobb, ha a kedves ügyfél vásárlással tölti az idejét, nem azzal, hogy keresi a virtuális liftet.

Node elnézést, ez nem egy marketing blog :) Most azonban biztonsági oldalról is kapott néhány nagy pofont az eddig is sok kritikával illetett technológia. A Context nevű biztonsági cég két összefoglalót is közzétett a WebGL-el kapcsolatos kutatásaiból, melyek eredményeként egyrészt a Mozillának frissítenie kell a saját implementációját, a Microsoft pedig leszögezte, hogy biztonsági megfontolásokból ebben a formában nem tudja elfogadni a specifikációt. Nézzük mit tárt fel a Context elemzése:

A problémák gyökere az, hogy a WebGL az operációs rendszer driverein keresztül képes kódot futtatni a grafikus magokon, ennek pedig több kellemetlen következménye is lehet.

A legalacsonyabb szintről indulva elmondhatjuk, hogy a grafikus kártyák tervezőinek célja a teljesítmény növelése, ami többnyire szöges ellentétben áll bármilyen biztonsági intézkedéssel, hardver szintű hardeningre tehát nem számíthatunk. 

A különböző driverekről elmondható, hogy más szoftverekhez hasonlóan itt is számolnunk kell biztonsági hibákkal, egy driverhiba kihasználása pedig gyakorlatilag minden esetben kernelmódú kódfuttatáshoz vezet (ezzel szemben egy sima böngészőhibával ring3-ba kerülünk, általában korlátozott, esetleg sandboxolt felhasználói hozzáféréssel). Eddig az ilyen jellegű problémák legfeljebb egy helyi támadó által voltak kihasználhatóak, mostantól egy kártékony oldalt működtető fél is hozzáférést szerezhet ezekhez az alacsony szintű modulokhoz.

A WebGL kódokat elsőként kézhez kapó böngészők nem tudják ellenőrizni, hogy valójában mit is akar lefuttatni egy adott weboldal. Ennek tipikus megnyilvánulása lehet egy DoS támadás: A támadó kérheti egy bonyolult objektum renderelését, de a kérés erőforrásigényéről nem lehet meggyőződni anélkül, hogy renderelnénk az objetumot... Így nem csak a böngésző folyamatot lehet kinyírni (javascript:while(1){}), de a teljes rendszer grafikai teljesítménye is megfogható, vagy akár BSOD is lehet az eredmény. Az egészben a legszebb, hogy a problémáról már a WebGL specifikáció is ír sőt, még PoC kódot is szolgáltat!

A különböző tartalmak típus és számrazási hely szerint történő védelmét aláássa, hogy a GPU-nak fogalma sincs arról, hogy egy adathalmaz milyen forrásból került hozzá. Egy WebGL alkalmazás például a böngésző segítségével betölthet külső forrásból származó képeket. A kép tartalmát egy, a kezdeményező weboldalon található szkript elméletileg nem ismerhetné meg, azonban ha ezt a képet textúraként felhasználjuk egy WebGL alkalmazásban, a GPU-n futó kód a textúra pixeleinek megfelelő időzítéseket alkalmazva információt továbbíthat a kezdeményező weboldal felé a kép tartalmáról. 

De nem csak a böngésző által kezelt adatok kerülhetnek veszélybe: A Context bemutatott egy olyan támadást, amely kihasználva, hogy a Firefox 4 WebGL implementációja nem inicializálja megfelelően a grafikus kártya memóriáját, lehetséges képernyőképeket menteni a weboldalt böngésző felhasználó asztaláról. Ezt a Mozilla június 21-én készül javítani, és valószínűleg magát a WebGL specifikációt is módosítani fogják.

És ezek csak néhány az új technológia kutatásában elért első eredmények közül, a fentieken kívül még sok érdekes információt találtok a Context két blogposztjában. Ezektől garantáltan elmegy a kedvetek a böngészőben Quake-ezéstől!