Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 262 reacties

Microsoft zegt dat WebGL gaat leiden tot een lange reeks moeilijk te verhelpen beveiligingsproblemen en wil de 3d-technologie voor browsers in zijn huidige vorm niet ondersteunen. Als alternatief hint de fabrikant op een eigen oplossing.

Met WebGL kunnen webdevelopers de browser, zonder plug-ins, 3d-beelden laten genereren. Versies van Chrome, Firefox, Safari en Opera ondersteunen WebGL, waarvan de Khronos Group begin maart de eerste versie uitbracht. Microsoft was echter afwezig op de lijst van bedrijven die de technologie ondersteunen.

In een blogbericht legt het bedrijf uit Redmond uit dat het naar aanleiding van een rapport met kritiek op de beveiliging van WebGL, een eigen analyse van de standaard heeft uitgevoerd. "De analyse heeft ons doen concluderen dat Microsoft-producten die WebGL zouden ondersteunen moeilijk door de Security Development Lifecycle-keuring zouden komen", aldus het Microsoft Security Response Center.

Een groot probleem vindt Microsoft dat browserapplicaties toegang krijgen tot videokaarten en de bijbehorende drivers, terwijl deze tot op heden nauwelijks rekening moesten houden met mogelijke malwaredreigingen. Niet alleen zou de WebGL zelf te maken krijgen met kwetsbaarheden, maar ook de vele drivers, waaraan browserbouwers weinig kunnen doen. Bijkomend probleem zou zijn dat de gemiddelde gebruiker niet gewend is zijn videokaartdrivers te upgraden, als er al nieuwe versies komen die de lekken dichten. "We verwachten dat er bugs verschijnen op bepaalde platforms of bij specifieke videokaarten en daarmee mogelijk doelwitten voor aanvallen", verklaart Microsoft.

De fabrikant wijst ook op het gevaar van denial-of-service-problemen en de gebleken ontoereikendheid van de huidige beveiligingsmaatregelen. "We zien de noodzaak om met oplossingen op dit gebied te komen, maar ons doel is ervoor te zorgen dat die veilig zijn wat ontwerp en uitrol betreft en dat ze by default veilig zijn", zegt het beveiligingsteam van Microsoft. Het bedrijf draagt zijn eigen Direct3D als alternatief aan, omdat hierbij onder andere door de restrictieve api's minder beveiligingsproblemen zouden spelen.

Moderatie-faq Wijzig weergave

Reacties (262)

Met de komst van GPGPU's kan het inderdaad een leuke manier zijn om malware te verspreiden. Als de browser (d.m.v. WebGL) toegang krijgt tot de driverlaag zou je eventueel code kunnen injecteren die gebruik maakt van de 'general purpose' van je GPU.

Misschien als de schrijver zeer goed is kan hij zelfs via WebGL via GPGPU dingen kunnen injecteren in het systeem zelf. Dat MS zijn eigen variant toegeeft is alleen maar gewoon, jammer dat dat helaas word afgeschoten door iedereen.

Je krijgt anders een beetje dit idee:

<insert fav automerk hier> "Ja meneer, auto's maken veel schade als er een ongeluk gebeurd. U kunt maar beter een fiets aanschaffen bij mijn buurman"

Terwijl ms zegt:

<insert fav automerk hier> "Ja meneer, auto's maken veel schade als er een ongeluk gebeurd. Wij raden u echter aan om onze auto's te gebruiken want daar zitten goede airbags en kreukelzones in"
Jeff Muizelaar heeft het artikel omgezet naar Silverlight 5 en vraaft zich af of er dan onwaarheden in zitten :)

Zie http://muizelaar.blogspot...l-considered-harmful.html
Jeff Muizelaar heeft er blijkbaar geen kaas van gegeten. Jeff denkt dat de vulnerabilities zitten in het zelf kunnen schrijven van HLSL code, maar dat is niet echt een issue. De kern van de zaak is dat WebGL direct met OpenGL communiceert, wat wordt geÔmplementeerd door de driver. Je bent dus niet afhankelijk van je browser-maker voor het oplossen van problemen, maar van de hardwarefabrikant die jouw GPU drivers levert.

Je hebt dus ten eerste geen standaard orgaan voor alle fixes die voor iedere gebruiker gelijk is, en ten tweede worden drivers nou niet echt bepaald vaak geŁpdatet door de gemiddelde gebruiker. Daarnaast ligt het niet in de aard van drivermakers om applicatie-invoer tot in den treure te gaan controleren. Dat hoeft vaak ook niet, op het moment dat je communiceert met een driver heb je toch al voldoende toegang tot het systeem. Behalve dus als je de driver blootlegt aan javascript, wat dus het geval is bij WebGL. Een browser heeft nou eenmaal een veiligere omgeving nodig, omdat de gebruiker code van derden uit aan het voeren is.

Dit is bij Silverlight anders, omdat die gebruik maakt van DirectX, die er op zijn beurt security hoog in het vaandel heeft staan. Onafhankelijk van wat voor hardware jij geburikt, als er een veiligheids issue ontstaat dan kan MS die fixen en dat pushen naar de client, en die fix geldt ook voor iedere gebruiker.
En daar zit dus een groot probleem waarom zou een gebruiker die met een driver kletst op eens meer rechten hebben dan de gebruiker heeft als deze met het bestandssysteem dan wel een stroperig trage tussen laag als DirectX praat?
Als je een OS bouwt dat claimt authentication en authorisation te ondersteunen maar je negeert dit alles op het moment dat een gebruiker een verzoek naar een driver stuurt dan is er toch iets goed mis in het model...

Ik neem aan dat Microsoft's conclusie niet geheel verzonnen is omdat MS weer eens geen zin heeft in een open standaard maar alleen met haar eigen DirectX wil werken of welke andere reden mensen hier achter zouden kunnen zoeken...
Maar als het inderdaad zo is dat je op het moment dat een gebruikers proces een driver aanspreekt alle acties die als gevolg van dit verzoek naar de browser worden uitgevoerd met veel hogere rechten verwerkt dan is dit een fundamentele fout in het security model van het OS en niet een reden om dan de standaard maar niet te ondersteunen. De conclusie zou moeten zijn we kunnen op dit moment nog niet omdat ons OS brak is en we dit eerst willen fixen.

Uiteindelijk doet DirectX niets anders dan OpenGL het is een laag tussen driver en applicatie die voor abstractie zorgt zo dat de programmeur niet hoeft na te denken over welke kaart er in het systeem zit, dat is aan de DirectX/OpenGL software om zich druk over te maken.

Dat Microsoft claimt dat hun DirectX beter is wat security betreft dan OpenGL is alleen maar waar omdat het onderliggende security model zo brak is dat de beveiliging in tussen lagen geregeld moet worden en niet door het OS en het driver model zelf geregeld kan worden. Ik heb geen idee of dit in andere OS'en beter is geregeld maar ik kan me toch niet helemaal voor stellen dat als ik als Linux guest gebruiker mijn SATA driver vraag mij te vertellen wat er op die root partitie staat dat deze vrolijk deze data ophaalt en even aan mij door geeft laat staan dat deze mij instaat zal stellen deze data te wijzigen alleen omdat ik toevallig rechtstreeks met de driver klets en en niet via een tussen laag...
Maar als het inderdaad zo is dat je op het moment dat een gebruikers proces een driver aanspreekt alle acties die als gevolg van dit verzoek naar de browser worden uitgevoerd met veel hogere rechten verwerkt dan is dit een fundamentele fout in het security model van het OS en niet een reden om dan de standaard maar niet te ondersteunen.
Waar staat dat het om hogere rechten gaat dan de app die met de driver communiceert? Dat is namelijk niet het geval - niet met WebGL, niet met OpenGL, en niet met D3D. Waar het om gaat is dat het bij een browser standaard niet mogelijk is om eigen code te runnen dat alle rechten heeft die de browser zelf heeft. Vanuit javascript kun je niet bij files in je documenten-map, ookal kan de browser dat wel. Door de WebGL calls zo op te zetten dat er een bufferoverflow oid triggert waardoor custom code uitgevoerd kan worden, dan kan een website die jij bezoekt dus plots ineens wťl bij je documenten zonder dat jij daar als gebruiker van de browser toestemming voor hebt gegeven. Snap je nu het punt waar het om gaat?

[Reactie gewijzigd door .oisyn op 17 juni 2011 17:30]

Mee eens, maar dat kan ook gebeuren in elke laag die gebruikt wordt in een browser, zelfs in de javascript implementatie, de browser zelf, DirectX, etc., etc.
Klopt, met het grote verschil dat browsers in de praktijk regelmatig worden geŁpdatet, maar drivers niet, plus het feit dat er in het geval van browsers maar 1 eindverantwoordelijke is voor de gehele userbase (de browservendor), en niet gefragmenteerd zoals bij drivervendors (omdat niet iedereen dezelfde hardware heeft). Zelfs al heeft een gebruiker shady hardware, dan nog zou de beveiliging er moeten zijn.

[Reactie gewijzigd door .oisyn op 17 juni 2011 21:10]

[...]

Waar staat dat het om hogere rechten gaat dan de app die met de driver communiceert? Dat is namelijk niet het geval - niet met WebGL, niet met OpenGL, en niet met D3D. Waar het om gaat is dat het bij een browser standaard niet mogelijk is om eigen code te runnen dat alle rechten heeft die de browser zelf heeft. Vanuit javascript kun je niet bij files in je documenten-map, ookal kan de browser dat wel. Door de WebGL calls zo op te zetten dat er een bufferoverflow oid triggert waardoor custom code uitgevoerd kan worden, dan kan een website die jij bezoekt dus plots ineens wťl bij je documenten zonder dat jij daar als gebruiker van de browser toestemming voor hebt gegeven. Snap je nu het punt waar het om gaat?
Snap het eigenlijk niet waarom een browser zowiezo bij mn files moet kunnen komen... In principe is het toch niet moeilijk , de browser gewoon geen rechten daartoe te geven... Het lijkt me gewoon dat ze dat wel kunnen hardcoden
Juist ja, want javascript kan zomaar automagisch bij OpenGL komen zonder dat de browser bouwers daar een tussenlaag voor moeten schrijven!

/sarcasme
Die tussenlaag die browsers implementeren is flinterdun, dat zijn alleen maar wat bindings tussen native en javascript functies. Het mooie van WebGL is dat een browser vrij "dom" kan zijn in het implementeren ervan, het enige wat ze hoeven doen is een simpele transformatie van een native API naar javascript. Semantische controle hoort daar helemaal niet bij, want daar is de API feitelijk zelf verantwoordelijk voor.

Het kŠn natuurlijk wel, en het is op dit moment ook de enige oplossing (laat ik voorop stellen dat ik het gebruik van D3D absoluut niet als een valide oplossing zie). Maar browsers doen dat momenteel dus niet, en dat is een ernstig issue!
http://www.contextis.co.uk/resources/blog/webgl2/

Ik zie liever dat de Khronos Group zelf met een validatielaag komt. Browsermakers zijn nou niet typisch de mensen met verstand van 3D API's en achterliggende implementatie, dus het is voor hen veel moeilijk om die edge cases te vinden en af te schermen. Bovendien zal iedere browsermaker dan hetzelfde werk moeten doen. Handiger is als er gewoon 1 organisatie is die dit doet, eentje die er bovenop zit, die de specs van de API zelf bedenkt en dus ook kan bepalen wat goede invoer is en wat niet.

Verder heb je nog het inherente probleem van OpenGL extensions, al weet ik niet in hoeverre die ook geexposed worden in WebGL.

[Reactie gewijzigd door .oisyn op 17 juni 2011 16:40]

Dat de laag flinterdun is op dit moment wil nog niet zeggen dat dat zo hoeft te blijven natuurlijk! Ik vind het van MS dan ook een beetje voorbarig om het op deze manier naar buiten te brengen, maargoed dat is mijn mening :)
Dat de laag flinterdun is op dit moment wil nog niet zeggen dat dat zo hoeft te blijven natuurlijk
Wel als het om Khronos ligt, die legt de verantwoordelijkheid bij de OpenGL implementeur:
GL_ARB_robustness has already been deployed by some GPU vendors and Khronos expects it to be deployed rapidly by others.
En heb je al gelezen wat OpenGL guru John Carmack ervan vindt?

Je moet me vergeven dat ik zijn mening boven de jouwe plaats ;)

[Reactie gewijzigd door .oisyn op 17 juni 2011 21:05]

Natuurlijk, maar die geeft de OpenGL API gewoon door. Stel dat als je een '2' meegeeft aan een OpenGL functie bij videokaart driver X dat je dan een BSOD krijgt en videokaart driver Y het wel goed afhandelt, ben je dus kwetsbaar als je driver X gebruikt.

Als een browserbouwer dat wil fixen mag hij gaan kijken naar wat voor drivers jij gebruikt en vervolgens voor elke driver een lijst met security issues gaan bijhouden voor ALLE beschikbare videodrivers en dat fixen in zijn WebGL implementatie 8)7
Wat wil Microsoft nou wel ondersteunen in hun browser... behalve hun eigen creaties waar eigenlijk niemand blij van word.

Nu hinten ze naar een eigen oplossing... maar die oplossing moet toch ook net zo goed beveiligd worden etc? Waarom steken ze die tijd dan niet in het beveiligen van WebGL?

[Reactie gewijzigd door Qre8ive op 17 juni 2011 14:33]

Nu hinten ze naar een eigen oplossing... maar die oplossing moet toch ook net zo goed beveiligd worden etc? Waarom steken ze die tijd dan niet in het beveiligen van WebGL?
Omdat Microsoft nou eenmaal een commercieel bedrijf is.

Toch moet ik zeggen dat Direct3D op dit moment een (veel) veiligere oplossing is dan WebGL. Met name omdat Direct3D als API-shell om alle drivers heen ligt, en er op deze manier de fabrikanten van de drivers vrijwel niet zelf aan (extra) beveiliging hoeven te denken voor web-rendering, dit doet Direct3D.

Het direct toegang verlenen aan de drivers is juist ťťn van de slechtere dingen die je kunt doen, vooral omdat deze letterlijk op hardware niveau opereren. Moet je je voorstellen binnenkort: Instructie-injecties in je videokaart, en mogelijk alle apparatuur die daarmee verbonden staat, en dit alles via een website. De droom van elke (assembly) hacker volgens mij..

[Reactie gewijzigd door KirovAir op 17 juni 2011 14:42]

Toch moet ik zeggen dat Direct3D op dit moment een (veel) veiligere oplossing is dan WebGL.
"Citation needed" zou op wikipedia hier binnen enkele uren verschijnen. :-)

Wat ik zie is dat een browser op de retour marktaandeel probeert terug te nemen door er voor te zorgen dat enkel hun browser en hun OS 3D capable is, en als de geschiedenis ons nu 1 ding heeft geleerd, dan is het wel dat dit geen goede zaak is voor de consument.

En het is niet omdat MS met wat fancy woorden schermt als 'restrictievere api' en 'moeilijk te verhelpen problemen' dat Kronos geen aandacht besteedt aan de veiligheid van WebGL. Hoewel ze ondertussen wel serieus zijn wakker geschud qua beveiliging denk ik niet dat MS ons de les in veiligheid moet spellen en in zijn eentje een beter product beter product gaat maken dan de rest samen...

edit:
Dat zie je toch verkeert, ze proberen Direct3D te slijten niet Internet Explorer
En op hoeveel platformen draait D3D denk je? Ik ken er maar 1. En ja: Concurrentie is goed, maar dit gaat over standaarden, daarvan heb ik er liever maar 1 per categorie. Ik denk ook niet dat het veel mensen blij maakt dat er een metrische een een amerikaanse standaard is voor lengtematen.

BTW: Denk je nu echt dat Google, Apple, Mozilla en Opera alle security issues gaan negeren om wat 3D te kunnen weergeven in hun browser???

[Reactie gewijzigd door iMispel op 17 juni 2011 15:12]

Dat zie je toch verkeert, ze proberen Direct3D te slijten niet Internet Explorer. Er is eveneens geen reden om aan te nemen dat WebGL geweldig is dus dit is weldegelijk een goede zaak voor de consument. Nu moet er kritisch naar de werking van WebGL worden gekeken in plaats van wat er uit komt. Er is nu concurrentie is goed voor de consument.
Kritisch ergens naar kijken is altijd een goed idee. Veiligheidsissues fixen ook. Direct3D naar voren schuiven als webstandaard, is dat niet.

[Reactie gewijzigd door kozue op 17 juni 2011 16:44]

BTW: Denk je nu echt dat Google, Apple, Mozilla en Opera alle security issues gaan negeren om wat 3D te kunnen weergeven in hun browser???
Negeren niet , maar misschien wel over het hoofd zien.
Een block list van drivers wat FF en chrome nu heeft is ook maar omslachtig.
Over het hoofd zien? Dat is nou precies een van de dingen die in OSS veel minder vaak voorkomen dan commercieel.
Waarom is direct3d veiliger dan opengl?

Beide zijn geschreven om snelle hardware/driver toegang te doen, hebben een grote complexiteit, er is immers beide een apart GPU taaltje wat beschikbaar wordt gemaakt . (shaders enzo). Beide leunen vervolgens op de videodrivers om dit te optimilisaren, waarbij drivers in beide gevallen beoordeeld zijn op snelheid en beeldkwaliteit (en zelden op beveiliging.

Web extensies die toegang krijgen tot de direct3d api zullen dus net zo goed kwetsbaarheden in de driver aantonen. toch?
Dit is een probleem wat we tegenwoordig veel meer tegenkomen, maar waar eigenlijk niemand bij stilstaat. Voorbeeld: hoeveel mensen weten dat een Firewire poort direct toegang heeft tot de systeemresources (geheugen, HDD enz), ook als de machine gelocked staat? En dat hetzelfde ook geldt voor Thunderbolt en ook voor ActiveX? In mijn ogen ziet Microsoft hier terecht een securityissue onstaan op een plek waar je normaal geen misbruik zou verwachten. HTML5 <video> maakt ook al gebruik van de videokaart/-drivers, maar daat zit de browser (met de codec) nog tussen, wat bij WebGL niet het geval is. Tijd voor een extra abstractielaag, of wellicht de hele browser in een sandbox zetten met strict gecontrolleerde interfaces naar de systeem hardware?
Die sandbox oplossing is zeker nodig, maar het brengt de browser weer terug naar het punt waar ze juist vandaan kwamen; minder lagen, dus sneller. Het lijkt erop dat ze iets te ver doorgedraafd zijn.
Dan bouwt MS toch een gesandboxde variant van WebGL in MSIE?

Waarschijnlijk 'kopieren' ze WebGL en sandboxen hem en maken hem incompatibel met WebGL en noemen het MS Dynamic Web 3D of zo.
Helemaal mee eens. Uiteraard komt Microsoft met een eigen (wel al lang in omloop zijnd) oplossing maar ze kaarten wel een goed probleem aan.

En eigenlijk is het wel terecht dat gebruiker X geen idee heeft wie waar rechten toe heeft, want hij is geen systeem architect. De gemiddelde gebruiker update nooit wat voor driver dan ook want de PC doet het en niemand zegt ze dat en hoe ze het moeten doet.

Ik vind ook zeker niet dat WebGL zo moet omspringen met de toegang tot bepaalde systeem onderdelen, het is een browser en die dient nogal laag op de toegangslijst van systeem resources te zijn want drive by infecties zijn aan de orde van de dag.
Een groot probleem vindt Microsoft dat browserapplicaties toegang krijgen tot videokaarten en de bijbehorende drivers, terwijl deze tot op heden nauwelijks rekening moesten houden met mogelijke malwaredreigingen.
Niet alleen zou de WebGL zelf te maken krijgen met kwetsbaarheden, maar ook de vele drivers, waaraan browserbouwers weinig kunnen doen.
Het bedrijf draagt zijn eigen Direct3D als alternatief aan, omdat hierbij onder andere door de restrictieve api's minder beveiligingsproblemen zouden spelen.
Welk deel van het artikel heb je wel gelezen?

[Reactie gewijzigd door Jeroen op 17 juni 2011 14:37]

"Wij van WC eend..." :Y)
Nouja MS heeft wel een punt, blijkbaar kun je met de huidige WebGL standaard kun je direct bij de videokaart drivers komen, terwijl dit volgens MS normaliter bij DirectX niet kan. Verder zouden beveiligings problemen in DirectX door MS zelf met een hotfix gefixed kunnen worden, terwijln het bij beveiligings problemen in een videokaart driver van Intel/AMD/Nvidia nog maar de vraag is hoe en of dit gefixed wordt, iig kan de browser maker (MS in dit geval) er niets aan doen, ook is het niet gewoon dat driver updates als automatische updates binnen komen. (Wel eens als optionele).

Aan de andere kant vraag ik me wel sterk af hoe je een bug in een driver zou kunnen exploiteren. Zo heel snel zou ik kunnen bedenken dat een website een call doet naar OpenGL en daar in het driver gedeelte probeert een buffer overrun te veroorzaken waardoor een stuk code in het geheugen kan worden gezet over bijvoorbeeld een andere functie van de driver heen. Dit geheugen kan daarna uitgevoerd worden door een call te maken naar die functie. (Dit is niet anders dan hoe normaal een buffer overrun bug misbruikt wordt). Maar of dit nu echt mogelijk is met OpenGL, en waar er precies een check ingebouwd zou kunnen worden in WebGL is me nog niet helemaal duidelijk.

Edit: zoals verder genoemd zou de hele browser in een sandbox draaien sowieso de veiligste oplossing zijn en zou dat ook dit probleem kunnen verhelpen, in Windows 8 zitten technieken hiervoor (zo gaan de geruchten) dus misschien dat het voor MS dan een minder heikel punt wordt.

Edit2: Hmm ik las net dat Khronos de beveiliging wel op orde had, maar in de Web GL security FAQ is er toch wat twijfel:
Defense against denial of service attacks is still evolving in WebGL implementations. Khronos has specified an extension to OpenGL and OpenGL ES, GL_ARB_robustness, designed to prevent denial of service and out-of-range memory access attacks from WebGL content, preventing any possibility of using WebGL to execute malware on a user's machine.
Edit3: Zelfs John Carmack van ID software is het met MS eens:
quote: John Carmack
http://twitter.com/#!/ID_AA_Carmack/status/81732190949486592
I agree with Microsoft’s assessment that WebGL is a severe security risk. The gfx driver culture is not the culture of security.

[Reactie gewijzigd door roy-t op 17 juni 2011 17:08]

In een uiterst geval zou je de firmware kunnen overschrijven en de GPU vervolgens dusdanig kunnen overbelasten dat deze oververhit raakt en wellicht in brand kan vliegen? Of ze ook in de BIOS kunnen komen lijkt me maar de vraag (want dan kun je echt helemaal los gaan), maar fysieke schade aan je machine komt hiermee wel een stap dichterbij. Of wat te denken van low-level keyloggers (mits ze wel in dat onderdeel terecht kunnen komen vanuit de GPU), de mogelijkheden zijn eindeloos.
Het OS levert voor geheugen op een computer een abstract dmv een uniforme interface, je kunt dus gewoon door het adres te veranderen switchen tussen GPU geheugen en RAM. Bijvoorbeeld het zou zo kunnen zijn dat adres 0~10000 is RAM en 100001~120000 is GPU-RAM. Dit was een van de redenen waarom je onder Windows XP32 bit met 4GB RAM maar +-3.2GB kon gebruiken (de rest van de adres ruimte mapte naar je video ram en andere buffers).

Dit houd dus in dat je door een bufferoverflow in GPU RAM, kunt lezen/schrijven in gewoon ram. hAl linkt hierboven naar een pagina van contextis waar ze een WEBGL demo hebben die text uit word documenten kan lezen als die open staan.

[Reactie gewijzigd door roy-t op 17 juni 2011 16:02]

U maakt er nogal een rotzooitje van, in het voorbeeld wordt slechts een screenshot genomen door uitlezen van de pixelbuffer. Die bug is reeds verholpen. Maar er wordt geen RAM van 'buiten de videokaart' gelezen oid. Mozilla stelt ook dat alle beweringen over 'toegang tot kernel-data' speculatief zijn.

Anders hoor ik graag met welk WebGL command men naar het geheugen kan schrijven? Voor zover ik weet, is zo'n commando er niet; want in WebGL doet men doorgaans geen geheugenmanagement.

[Reactie gewijzigd door kidde op 17 juni 2011 16:52]

Eh een bufferoverflow maakt het mogelijk om door een pointer naar een te grote array mee te geven geheugen te overschrijven, doordat het programma geen rekening hield met een te grote array schrijft het per ongeluk voor jou iets naar geheugen waar jij zelf geen toegang tot had. Wat betret screenshot, daar ga jij ook een beetje te kort door de bocht, het is geen screenshot wat gemaakt wordt, maar er wordt in 'oud' video geheugen gezocht naar data die de vorige screenbuffer(s) voorstelde en a.d.h. daarvan wordt een nieuw plaatje geconstrueerd.
Mozilla stelt ook dat alle beweringen over 'toegang tot kernel-data' speculatief zijn.
Maar het is verre van uitgesloten! Dat is het probleem.
Je vergeet dat je video geheugen niet per se allemaal op de kaart zit. Er kan ook mobo ram gebruikt worden. En het zou me niks verbazen als een videodriver onder windows rustig buiten z'n toegewezen ruimte kan schrijven.
Ik denk dat je een beetje te ver gaat. Het BIOS is niet zomaar iets om bij te kunnen.

Ben zelf nu ook bezig voor school met WebGL, maar het is niet zo makkelijk om je videokaart aan te spreken als met bijvoorbeeld OpenGL zelf. Dus denk dat het wel mee zal vallen.

Daarnaast gooit Microsoft de hardware redelijk dicht, in mijn geval minder leuk, wat wel goed is als je er geen code rechtstreeks naar toe schrijft. Dus er zit nog een redelijke laag tussen de driver en je kaart.
Met de huidige BitCoins hype zie ik wel een distributed GPU-farming botnet ontstaan :)
Deze weet m'n MacBook Late 2007 van tijd tot tijd toch best wel vast te laten lopen vanuit Chrome:

http://people.mozilla.com/~sicking/webgl/mandjulia.html

[Reactie gewijzigd door Henk Poley op 17 juni 2011 15:47]

Dit komt omdat MS geen GL implementatie heeft en hiervoor afhankelijk is van de videokaartdrivers. Als MS een GL tussenlaag heeft en hier WebGL op af zou beelden is het gelijkwaardig met de Direct3D oplossing. MS heeft tegenwoordig geen OpenGL meer (vroegah wel) omdat het concurreerde met DirectX. Dus zover ik kan zien heeft men zelf het probleem gemaakt.
Voor de mensen die niet snappen waar dit over gaat:
http://www.youtube.com/watch?v=YsvHeLUOoxs

TheDarkstar doelt op het feit dat Microsoft weer met iets beters denkt te moeten komen terwijl er met WebGL volgens hem en vele anderen niets mis is.
terwijl er met WebGL volgens hem en vele anderen niets mis is.
Het is niet alsof Microsoft de enige is die gevaren zien in WebGL

http://www.contextis.co.uk/resources/blog/webgl2/

[Reactie gewijzigd door 80466 op 17 juni 2011 15:47]

Wow, in dat document staat gewoon een proof of concept om geheugen van andere processen uit te lezen dmv WebGL en de ATI drivers, dat is wel een erg grote security flaw!

Edit: ook Mozilla zelf ziet problemen http://blog.jprosevear.org/2011/05/13/webgl-security/ maar denken het te kunnen oplossen dmv een extensie op WebGL.

[Reactie gewijzigd door roy-t op 17 juni 2011 15:58]

WebGL is een API en is per definitie niet onveilig. De implementatie kan dit wel zijn en dat is dan ook bewezen.
Het is niet zo zeer dat WebGL onveilig is. Het is alleen zo dat er nu een tunnel is direct naar je computer toe.

Waar een paar jaar geleden toen we massaal begonnen met TABS in een browser de ontwikkelaars elke TAB een eigen SandBox gaf. Haalt WebGL op dit moment deze veilige SandBox weg. Waardoor een Browser API weer direct toegang heeft tot de computer.

Het staat nog in de kinder schoenen. Zal nog veel moeten gebeuren om dit verder door te ontwikkelen. belangrijk puntje..

Alles begint met een JA MAAR. uh we moeten vooruit kijken. Goed dat een nieuwe nutige feature in ontwikkeling is. Nu kijken hoe we het veiliger kunnen maken zonder al te veel performance in te leveren. Nieuwe programatuur zullen altijd problemen zijn, daar kom je vaak achter pas als je het uitbrengt en aan het grote publiek laat testen.
MS heeft op zich ook niet ongelijk. Videokaartdrivers met OpenGL implementaties hebben vaak bugs, en door deze API te openbaren in browsers kunnen deze bugs ernstige(re) gevolgen hebben.

Ik ben er overigens niet van overtuigd dat Direct3D implementaties dat zoveel beter voor elkaar hebben, dus de FIPO heeft als je het mij vraagt misschien wel een punt :) Afgezien van dat, Direct3D als alternatief aanbieden druist een beetje in tegen het hele idee achter interoperabiliteit van de HTML5 standaarden enzo, lijkt me :/
WebGL != OpenGL, en ik zou zo ook niet kunnen verzinnen waarom je geen WebGL support in je browser zou kunnen bouwen die DirectX gebruikt voor rendering. Dus dat lijkt me geen argument.
WebGL is natuurlijk wel een API die in grote lijnen het model van OpenGL volgt, en een bug in een OpenGL implementatie (als deze gebruikt wordt door een WebGL implementatie) is dan mogelijk uit te buiten via WebGL, maar inderdaad, een API is een API en je kan er van alles achter stoppen. Ik denk dat het werkelijke achterliggende probleem is dat OpenGL/Direct3D implementaties gewoon niet ontwikkeld zijn met het idee dat ze vanuit onbetrouwbare bronnen aangeroepen kunnen worden.

Ik hoop dat MS WebGL niet voorgoed afwijst, ik denk dat het toch de enige mogelijkheid zal zijn om crossbrowser 3D acceleratie te kunnen benutten in websites. Aan de andere kant zou het ook erg jammer zijn als er zich straks allemaal beveiligingsproblemen voordoen met WebGL door brakke implementaties, dat zal ongetwijfeld gevolgen hebben voor de adoptie er van.
Ja denk gewoon aan Direct3D Model Occlusion Exploit of Direct3D Inferface Hooking en zo zijn er nog velen iets waar ja met WebGL ook wel degelijk rekening mee moet houden dat dit gewoon mogelijk is , vooral de Hooking die ongemerkt kan gebeuren zonder crashes of antivirus waarschuwingen omdat het direct geÔnjecteerd kan worden enzo.

Dus ik kan idd MS ook geen ongelijk geven.
Het is niet gek dat een dergelijke techniek - die eigenlijk nog in de kinderschoenen staat - nog niet 100% veilig is. Er zat in de komende jaren vast veel nagedacht worden over hoe webGL via aanpassingen veiliger gemaakt kan worden. Overigens zie ik liever webGL dan een alternatief van Microsoft; na ActiveX is het vertrouwen in dergelijke 'veiliger' software van die partij toch wel wat gedaald (bovendien kan Microsoft Direct3D in de toekomst misschien weer exclusief maken voor IE in een poging het marktaandeel op te krikken).
Uhm WebGL = Opensource. Direct3D niet?

MS wil hier gewoon een slaatje uit slaan. Onzin... Wat ik heb gezien met WebGL is mooi en ik vind het de toekomst samen met HTML5 voor de onderliggende basis.
MS is sowieso heel erg tegen opensource als je balmer mag geloven... egoÔsten. Het Web moet gewoon Opensource en niet van iemand zijn!

WebGL is nog jong. En het is mooi dat mensen er nu al security flaws in vinden. Dit is dus nog op te lossen voordat het grootschalig wordt.

Daarnaast is het Web niet alleen op Windows maar op allerlei OSen te vinden waar geen Direct3D op te vinden is. Krijg je het Adobe Flash idee....

[Reactie gewijzigd door Texamicz op 17 juni 2011 16:41]

WebGL kan we lmooi zijn, maar is het veilig? Dat is hier de vraag, Microsoft (en zeker niet alleen Microsoft) zien beveiligingsproblemen in WebGL. Dat Microsoft hier geld mee wil verdienen is onzin, ja als ze het zullen verkopen aan andere browser, schrap Mozilla al maar van de lijst, want zij willen enkel open soucre, dan kunnen ze er geld aan verdienen. Maar als je het zo leest, gaat het niet om geld, het gaat om VEILIGHEID, veiligheid die volgens Microsoft blijkbaar te laag is bij WebGL om het in IE te stoppen.
De Mozilla foundation is een non-profit organisatie. Winst maken zal dus waarschijnlijk niet het doel zijn dat ze voor ogen hebben. Wellicht wel de firefox developers die voor de Mozilla corporation werken maar ook die zullen waarschijnlijk niet geld als grootste drijfveer zien ;)

Laat Microsoft maar fijn meewerken aan de veiligheid van webgl welke zelfs op mijn telefoon (Nokia 900 met de nodige firmware updates) draait. Het alternatief dat zij aanbieden zal Windows only zijn, wellicht met een beetje geluk ook te gebruiken op xbox en WP7. Denk dat meeste webontwikkelaars er ook niet op wachten, websites hebben juist als voordeel dat ze op elk apparaat met een browser werken.

[Reactie gewijzigd door Xthemes.us op 17 juni 2011 23:28]

Ik betwijfel of iets "Windows only" de dag van vandaag nog van de grond kan komen. Het markaandeel van Apple alleen al is zo'n 10% en het markaandeel van IE is nog maar 55%.
Kijk bvb maar eens op de site van w3schools naar de browserstatistieken, daar is het maar 25% meer.
Als de andere browsermakers wel kiezen voor WebGL dan kan MS het niet maken om met een eigen D3D alternatief te komen.
Het probleem van de veiligheid is hier secundair. Microsoft heeft een groot verleden van onveilige software met als toppunt ActiveX wat nog steeds gebruikt kan worden. Dit is gewoon een verhaaltje om Silverlight in stand te kunnen houden (waarom Silverlight als er een echte standaard is..)
Bij software staat veiligheid als eerste op de agenda.

Microsoft heeft hier een goed punt. Wanneer websites softwarematig toegang krijgen tot het aansturen van drivers en videokaarten, zal dit inderdaad veiligheidscomplicaties opleveren.

Het is niet anders dan dom om te stellen dat veiligheid altijd later opgelost kan worden. Eerst klagen dat 'vandaag de dag bedrijven als Sony en Citigroup gehackt kunnen worden', en vervolgens deze uitkomsten afdoen als onbelangrijk.

Deze 3d aansturing in websites met videokaart ondersteuning is heel leuk en aardig, maar waarom denken jullie dat het voorheen niet mogelijk was? Omdat het niet gemaakt kon worden? Ben je gek. Puur om dit soort veiligheidsproblemen waar ze voor alsnog geen oplossing voor hebben. Nu hebben de andere partijen alleen gekozen om dit te negeren.
Bij software staat veiligheid als eerste op de agenda.
En daarom werkt deze FUD-aanpak ook zo goed.

Ook bij websockets, een ander onderdeel van html5, zijn er nog forse veiligheidsissues te overwinnen. Toch is dit wel onderdeel van de standaard, kennelijk zonder veel protest van Microsoft. Op die manier is er voortgang mogelijk: diverse browsers hebben het al geÔmplementeerd, maar veiligheidshalve standaard uit staan.

Dat zou ook voor WebGL prima kunnen: standaardiseren, beginnen met inbouwen en gebruiksmogelijkheden ervoor te ontwikkelen en ondertussen zien voor welke van die mogelijkheden het op welke manier veilig ingeschakeld kan worden. Dus, ik acht het FUD van Microsoft om deze kaart zo te spelen, bedoeld om andere belangen af te schermen.
Websockets van microsoft is ook alleen nog in hun html 5 labs te vinden omdat de spec niet klaar is en nog niet alles super is.
http://html5labs.interoperabilitybridges.com/
Oh dus omdat iets vroeger was kan het niet zijn dat security nu wel een speerpunt is van Microsoft? Ze hebben hun leven namelijk stukken verbeterd de afgelopen jaren.
Oh dus omdat iets vroeger was kan het niet zijn dat security nu wel een speerpunt is van Microsoft? Ze hebben hun leven namelijk stukken verbeterd de afgelopen jaren.
Tuurlijk. IE 7 had namelijk 100% veilig kunnen zijn als het aan het development team had gelegen.
Probleem was daarmee dat allerlij "leuke" dingen van MS dan niet meer zouden werken, zoals het kunnen "tracken" van gebruikers via allerlij advertentie sites (van MS en anderen, adsence, google etc). En zo is die functionaliteit er dus niet ingekomen... (ook niet in 8 en 9!)
Dat dus allemaal voor het (advertentie) geld...

Dus MS en veiligheid.... Alleen als het geld oplevert bij MS ;) (wedden dat Win 8 *nu nog veiliger* is dan Win7? Als je maar schuift ;))
gaat het niet om geld, het gaat om VEILIGHEID, veiligheid die volgens Microsoft blijkbaar te laag is bij WebGL om het in IE te stoppen.
Volgens mij is dit het zelfde als hoe X geÔmplementeerd is op Linux. X heeft ook directe toegang tot de video kaart. Daarom is Windows ook Vele male veiliger dan Linux... :|
je vergelijkt nu 2 verschillende zaken met elkaar.

X is een interface om Linux gebruikers van een grafische omgeving te voorzien.
Dit kan je vergelijken als de grafische interface van Windows zonder de explorer shell.

Standaard heeft alleen de localhost, toegang hier tot. En anders kan je aangeven wie hier een verbinding mee kan maken.

Wat ik van het verhaal hierboven lees, is dat kwaadwillende, die een website beheren, via Webgl toegang hebben tot de videogeheugen. Waardoor ze als het ware realtime screenshots kunnen maken van de beelden die een gebruiker in zijn videogeheugen heeft.

Bij X is deze manier, totaal niet aan orde. Hoewel het via andere manieren wel mogelijk is om de beelden af te tappen. Maar dat kan bij Windows als Macosx als bij andere OS'en met een grafische of commandline omgeving ook. Die manieren zijn totaal anders dan de Webgl lek wat hierboven is beschreven.

[Reactie gewijzigd door romanotjonfo op 17 juni 2011 23:12]

WebGL kan we lmooi zijn, maar is het veilig? Dat is hier de vraag, Microsoft (en zeker niet alleen Microsoft) zien beveiligingsproblemen in WebGL. Dat Microsoft hier geld mee wil verdienen is onzin, ja als ze het zullen verkopen aan andere browser, schrap Mozilla al maar van de lijst, want zij willen enkel open soucre, dan kunnen ze er geld aan verdienen. Maar als je het zo leest, gaat het niet om geld, het gaat om VEILIGHEID, veiligheid die volgens Microsoft blijkbaar te laag is bij WebGL om het in IE te stoppen.
Wat dan ook te denken geeft aan IE, maar daar lees je niets over... ;) Ik weet dat de beveiliging flink verbeterd is tov IE6, maar misschien is daar de beveiliging ook (nog) niet goed... ;) IE9 is immers ook zo oud nog niet!
schrap Mozilla al maar van de lijst
IIk denk dat je daar de hoofdreden hebt voor Microsoft's eigen standaard. Een vrije standaard die over alle platformen heen uniform werkt zou teveel zagen aan de poten van de Microsoft hegemonie.

Microsoft zou beter verbeteringen kunnen voorstellen aan WebGL. Maar tenzij de markt ze daartoe dwingt, zie ik dat niet snel op een constructieve wijze gebeuren.

[Reactie gewijzigd door 125509 op 19 juni 2011 12:35]

En de andere helft van Microsoft komt uit de kast. Samenvatting: de kans dat MS geen WebGL ondersteunt is 0, ze zouden gek zijn als de rest van de markt het wel doet.
Als Microsoft haar zin krijgt word het web net zoals de OSen, dan hebben we straks geen enkele keus meer wat voor browser we kunnen gebruiken want veel websites werken niet meer op fatsoenlijke browsers.

Domineren en monopoliseren, onafhankelijk van hoe slecht de producten wel niet zijn.
Microsoft is zeker begonnen met "laat ik op een toetsenbord schijten en zien wat er gebeurt".
Sowieso, 100% veilig is een sprookje. Het is zoals de fipo zegt, 'wij van wc-eend'... MS wil gewoon te graag de voorloper zijn, dat dit leid tot wederom verbastering van webstandaarden (of toekomstige) interesseert ze niets. Buiten dat WebGL wordt ontwikkeld door de concurrent op browser gebied...
Ik denk dat MS toch echt wel verstand heeft van security hoor. Windows is het platform met de meeste dreigingen omdat het gewoon zo populair is. Al die mensen met macs en linux die zeggen dat Windows onveilig is moeten zich wel bedenken dat linux en mac os nauwelijks gebruikt wordt.

Al zie je dat mac os ook steeds meer dreigingen krijgt.

En het klopt gewoon dat veel mensen hun video drivers niet upgraden.

Toch zal hier een stukje promotie van hun eigen Direct3D natuurlijk een rol spelen, alles wat pas uit komt heeft bugs en lekken.
MS heeft tegenwoordig meer verstand van security maar het is verre van optimaal en als je kijkt naar het verleden zie je een trend van fail na fail met als summum een verplichte cursus secure programmeren voor alle medewerkers ergens in 2002 (werd nota bene aangeprezen als iets positiefs).
Na fijne dingen als ActiveX in een browser kun je wel vergeten nog serieus genomen te worden in security land.
De beveiliging van Xbox Live zit anders prima in elkaar (itt die van Sony blijkbaar). En er zijn nog meer terreinen waar de beveiliging van Microsoft systemen of applicaties prima werkt. Omdat het zo'n groot bedrijf is, zijn er een hoop dingen die fout kunnen gaan, maar dat wil niet zeggen dat ze er niet mee bezig zijn. Ze zullen ook wel weten dat ze van ver moeten komen, maar langzamerhand zijn ze toch wel op de goede weg.
Ik denk dat MS toch echt wel verstand heeft van security hoor. Windows is het platform met de meeste dreigingen omdat het gewoon zo populair is. Al die mensen met macs en linux die zeggen dat Windows onveilig is moeten zich wel bedenken dat linux en mac os nauwelijks gebruikt wordt.
Misschien moet je eens onder die steen vandaan komen. Linux wordt niet gebruikt? Op de desktop misschien... De meeste webservers draaien Linux. Webservers hebben geen security nodig ofzo? Als ik een black hat hacker was zou ik wel weten waar ik liever in zou breken, een webserver met flink wat storage en bandbreedte of jouw saaie thuisdesktopje met je vakantiefoto's en mp3 collectie. Die eerste is natuurlijk veel interessanter. Het is dus complete onzin dat Windows zo vaak gehackt wordt omdat er zoveel Windows gebruikers zijn, Windows is gewoon een makkelijk slachtoffer.
Scheelt natuurlijk wel dat een webserver niet door je oma gerund wordt. Daar zitten doorgaans toch wel iets meer technisch onderlegde personen achter, die weten hoe ze een systeem dicht moeten timmeren.
Je geeft het overigens zelf ook al aan - webservers hebben ook security nodig. Dus is Linux ook niet veilig genoeg om out-of-the-box potdicht te zitten...
Daar heb je dan ook de vele distro's voor, onder opensuse is apache standaard aardig dichtgetimmerd. htaccess files en php error logging zijn standaard b.v. disabled. Niet zo handig voor je development server, wellicht wel leuk voor je productieserver.

Maar zoals ik al eerder poste, het staat microsoft vrij een bijdrage aan webgl te leveren. Of het OS standaard deze gevaarlijke ATI drivers te laten updaten.
Ik denk dat je een belangrijk argument over het hoofd ziet: Windows wordt ook door consumenten gebruikt en die zijn niet altijd even snugger of geinteresseerd. Daardoor loopt de beveiliging bij een hoop mensen achter, waardoor de kans op breuken gewoon groter is. Dat weten hackers ook dus die gaan natuurlijk niet proberen een zwaar beveiligde server te hacken, maar pakken gewoon simpele pc's om een botnet op te zetten. Daarom zijn die er ook zoveel.

Daarnaast wordt Linux wel degelijk geupdate en gepatched, maar omdat de beveiliging gewoon vanaf het begin goed is meegetrokken (onder andere vanwege de webfunctionaliteiten) heb je minder snel het idee dat je de voordeur van de server open hebt staan.

Er zijn een hoop bedrijven die zich specialiseren in beveiliging voor webservers. En die zijn voor zowel Windows als voor Linux. Linux is out-of-the-box ook niet zo veilig om meteen online te zetten. Daar zul je ook wel een firewall of virusscanner bij moeten zetten om in ieder geval de meeste aanvallen af te weren.
Een virusscanner op Linux...
De virusscanners die bestaan voor Linux scannen alleen maar naar Windows virussen die niets kunnen uithalen op een Linux systeem.
Die twee proof-of-concept virussen die 'bestaan' voor Linux zijn daarbij nog nooit "in the wild" gevonden.
http://en.wikipedia.org/wiki/Linux_malware

Volgens mij word 't tijd om wat bronnen na te lopen :)
Microsoft heeft verstand van security want het moet regelmatig beveiligingsproblemen met haar software oplossen met allerhande patches.

Ik het er net 11 geÔnstalleerd voor het summum van veiligheid: Windows 7.

[Reactie gewijzigd door fevenhuis op 17 juni 2011 16:30]

Het aantal updates zegt helemaal niets over de beveiliging. Een hoop patches worden dubbel geleverd omdat niet iedereen alle functionaliteiten van windows heeft geactiveerd. Daardoor zul je voor programma X een patch krijgen, maar voor programma Y ook, terwijl die misschien allebei op de pc staan.
Verder zitten er zoveel componenten in Windows dat er veel zaken kunnen worden misbruikt, welke ze uiteindelijk moeten aanpassen.
Er zijn analisten die zeggen dat Mac OS en Linux zelfs nog een slechtere beveiliging hebben dan Windows, zeker als ze even groot zouden zijn.
Gesponsord door Microsoft :+
Er zijn analisten die stellen dat linux waterdicht is

Zo, mijn tegenargument!
Zo hebben we MS en andere OSen Bash ook weer gehad.

Elke PC met ELK OS is zo veilig als de beheerder van deze machine. Op mijn OSx Machine staat ook alles dicht. en als ik naar mn log bestanden kijk op mn Apache server die gehost wordt op een OSx machine zie ik heel veel pogingen om iets anders te doen dan alleen een pagina opvragen.

Zelfde zie ik ook op mn werk. waar ik TMG heb draaien. verrot veel pogingen om door de firewall te breaken!!
Dat MS met iets beters denkt te komen? MS had al een oplossing. WebGL is juist een systeem van iemand die met iets beters denkt te komen. Wat misschien wel en misschien niet klopt.
Bedoel je Silverlight?
Moet je eens het orginele artikel en whitepaper goed doorlezen, ze komen gewoon met feiten, dit is dus voortgekomen uit een fatsoenlijk security onderzoek..
precies wat ik dacht,... wij van Microsoft adviseren om geen open source oplossingen te gebruiken, maar het door ons gepatenteerde produkt, met alle door ons opgelegde beperkingen.
Ik vind het echt weer van een ongekende simpelheid, weer gaat microsoft de ontwikkeling van het internet tegenhouden, omdat ze denken meer macht te krijgen.
Weer gaan ze de concurrentie in de kaart spelen, waardoor er nog meer mensen gaan overstappen naar chrome, firefox, safari, etc.
Weer blijven we zitten met een internet waarbij er van alles kan, maar niet op IE.
Zucht,.... ik dacht dat met de introductie van IE9 ze begrepen hadden dat je met je tijd mee moet gaan.
dom, dom, dom.
Het bedrijf draagt zijn eigen Direct3D als alternatief aan, omdat hierbij onder andere door de restrictieve api's minder beveiligingsproblemen zouden spelen.
  • Als Microsoft Direct3D als een volledig open standaard aanbiedt (zonder patentproblemen, dus ook voor bv GPL open source bruikbaar!) bij de standards body (zoals ISO/Kronos), net zoals OpenGL, dan zou dat misschien een mogelijkheid zijn.
  • Waarom denkt Microsoft dat Direct3D niet dezelfde problemen kan bevatten? Als mensen gaan zoeken, zullen ze waarschijnlijk dingen gaan vinden...
  • Als mensen hun videokaartdrivers niet updaten, zal dat ook voor Microsofts versie van WebGL een probleem vormen...
Waarom denkt Microsoft dat Direct3D niet dezelfde problemen kan bevatten? Als mensen gaan zoeken, zullen ze waarschijnlijk dingen gaan vinden...
Omdat de front-end van D3D niet wordt geÔmplementeerd door de driver zoals bij OpenGL maar door Microsoft zelf, die op zijn beurt weer communiceert met een D3D backend die door de driver wordt geÔmplementeerd. Deze tussenlaag maakt het mogelijk om extra controles uit te voeren en restricies op te leggen aan de gebruiker van de API.
MS was toch met Vista van plan om toegang tot OpenGL alleen te geven via een wrapper? Waarom kunnen ze dat plan niet weer uit de kast halen voor browsers? Geeft vast iets minder performance, maar iets is beter dan niets.

Dadelijk moeten we voor 3d-animaties op webpagina's weer een OpenGL en D3D variant maken, net zoals dat vroeger wel gedaan werd met spelletjes |:(
Niet mee eens. Native games hebben dergelijke security niet nodig, en zouden daar dus ook de prijs niet voor hoeven te betalen. Ik zie liever dat de Khronos group de OpenGL API in tweeŽn deelt, zoals dat bij D3D ook het geval is. Een eigen (open source) implementatie van de front-end met wellicht meerdere security niveaus (of gewoon meerdere implementaties), en een door de driver geÔmplementeerde backend.

Nou is dat bij OpenGL al wel een stuk lastiger omdat de driver extensies aan de applicatie aan kan bieden. Op het moment dat er een front-end voor zit kan dat niet meer.

Waar ik het wťl mee eens ben is dat het dķs maar gebruik maken van D3D absoluut geen oplossing is :). Er moet gewoon 1 standaard API zijn, punt.

[Reactie gewijzigd door .oisyn op 17 juni 2011 16:21]

En WebGL wordt ook niet geimplementeerd door de driver bouwers maar door de browser bouwers, wat is je punt???

WebGL is gebaseerd op OpenGL ES, van embedded systems, het is dus niet een 1 op 1 geval, er zit iets tussen de javascript code en wat uiteindelijk bij de video drivers terecht komt...

Ook bij deze laag (de WebGL laag) kan men extra controles uit voeren.....
Dat zou een goede zet zijn, Direct3D open source te maken. Wordt het porten van games ook ineens een stuk makkelijker. Dit zou voor veel mensen de overstap naar bijvoorbeeld linux flink vereenvoudigen. Veel gamers zouden best willen overschakelen naar linux, maar doen dit niet vanwege games die daarop niet draaien.
Die gamers waar je 't over hebt kunnen dan vandaag al over stappen op linux. Vroeger, toen ik aleen windows gebruikte, had ik al een dualboot. 1 snelle voor gamen geoptimaliseerde windows (zonder virus scanner, fileshares, services, etc.) en 1 windows voor het nuttige werk. Dat kan natuurlijk ook met een windows om te gamen en een linux voor het nuttige werk.
De API Wars all over again!

10-15 jaar geleden was het precies hetzelfde verhaal. Alle ontwikkelaars gebruikten OpenGL. Microsoft kwam toen met de eigen oplossing; Direct3D. In de eerste jaren gaven ontwikkelaars de voorkeur aan OpenGL. Maar Microsoft bleef pushen en verzaakte het implementeren van een goeie standaard OpenGL driver in Windows. Hierdoor leek OpenGL langzaam ivm Direct3D. SGI heeft toen een verbeterde driver geschreven die OpenGL 2x zo snel maakte ivm de standaard Microsft driver.

Later was er sprake van dat Microsoft het gebruik van OpenGL nagenoeg zelfs onmogelijk zou maken in Windows XP. Zover is het uiteindelijk niet gekomen, maar voor OpenGL ben je sindsdien helemaal afhankelijk van drivers van de fabrikant. De standaard drivers die met Microsoft meegeleverd worden ondersteunen ook niet/nauwelijks OpenGL.

We zien weer precies hetzelfde; WebGL komt als eerste serieuze 3D api voor het web. Microsoft gaat de boel downplayen en zal straks wel met een eigen (op Direct3D gebasseerde) versie komen die uiteraard niet onder MacOSX of Linux werkt.

Laten we hopen dat Khronos (beheerder van OpenGL/WebGL/OpenGL ES) geleerd heeft van het verleden en ervoor zorgt dat WebGL een moderne standaard is en blijft zodat dit geen herhaling wordt van OpenGL vs. Direct3D.
In de eerste jaren gaven ontwikkelaars de voorkeur aan OpenGL.
Inderdaad. Met name omdat Direct3D tot en met versie 7 behoorlijk ingewikkeld in elkaar zat. Echter, toen kwam Direct3D8, die het roer volledig omgooide, en sindsdien zijn developers het gaan omarmen. Op zich niet geheel onterecht, OpenGL was destijds een log en stuurloos schip, de API hopeloos verouderd en als je als applicatie van moderne technologie gebruik wilde maken was je afhankelijk van bakken vol aan vendor-specifieke extensies, waardoor je gedwongen werd dezelfde feature op verschillende manieren te implementeren voor verschillende soorten hardware. Jeeeeej standaard! *kuch*

Op zich heeft de slechte support voor Windows weinig te maken gehad met de ondergang voor OpenGL in de gamesindustrie, daar de standaard zelf behoorlijk debet aan.
Laten we hopen dat Khronos (beheerder van OpenGL/WebGL/OpenGL ES) geleerd heeft van het verleden en ervoor zorgt dat WebGL een moderne standaard is en blijft zodat dit geen herhaling wordt van OpenGL vs. Direct3D.
Helemaal mee eens! Laat ze eens beginnen met de API zo opzetten dat ze een eigen front-end implementatie leveren van de API, en dat drivers alleen een backend hoeven te implementeren. Kunnen ze meteen alle issues oplossen waar Microsoft nu geheel terecht voor waarschuwt, en hebben we straks gewoon 1 GL standaard :).
Een groot probleem vindt Microsoft dat browserapplicaties toegang krijgen tot videokaarten en de bijbehorende drivers
En als je Windows gebruikt krijgen alle applicaties toegang tot het hele systeem. what's your point MS?
Dat je via een browser toegang krijgt tot lowlevel hardware aansturing?
Browser support for WebGL directly exposes hardware functionality to the web in a way that we consider to be overly permissive

The security of WebGL as a whole depends on lower levels of the system, including OEM drivers, upholding security guarantees they never really need to worry about before. Attacks that may have previously resulted only in local elevation of privilege may now result in remote compromise. While it may be possible to mitigate these risks to some extent, the large attack surface exposed by WebGL remains a concern. We expect to see bugs that exist only on certain platforms or with certain video cards, potentially facilitating targeted attacks.
We expect to see bugs that exist only on certain platforms or with certain video cards, potentially facilitating targeted attacks.
Dit zie ik ook alleen maar gebeuren op Windows, OSX of Linux systemen hebben aanzienlijk minder last van virussen of bug-abuse.

Mijn punt is; microsoft was vanaf dag 1 al hard bezig om openGL, openAL, en nu ook webGL de grond in te boren voor hun DirectX systeem. Terwijl in vele gevallen OpenGL betere performance en grafische kwaliteit levert dan DirectX.

Ook Flash en Java heeft toegang tot je hardware... en tot nu toe is dit geen groot probleem gebleken in verband met security.

[Reactie gewijzigd door Blue_Entharion op 17 juni 2011 15:01]

De enige reden dat OSX of Linux systemen aanzienlijk minder last hebben van virussen of bug-abuse is omdat deze aanzienlijk minder gebruikt worden nog steeds waardoor het niet echt interessant is om hier tijd aan te besteden.. Heb je de securityissuelists wel eens bekeken van OSX en een gemiddelde Linux distro? die is dus uitgebreider dan die van Windows 7...
Linux distro is OS + een hele lijst van toepassingen. Wil je een vergelijking maken van de security fixes, dan moet je de lijst voor een linux distro dus vergelijken met de lijst van fixes voor Windows + MS-Office + MS-Sqlserver + Sharepoint + een heleboel andere toepassingen die MS op de markt brengt.
Uhm, java draait in een VM en heeft nou juist geen directe toegang tot je hardware...
Vandaar de eindeloze lijst met security updates voor flash.
We hebben het hier niet over virussen, maar over browser exploits. En kijk de security historie van Safari maar even door, het stikt van de fixes.
Sorry hoor, maar een MacOSX,iOS,Linux,Android applicatie heeft ook net zo veel toegang tot het systeem als dat een windows applicatie heeft in Windows 7..
En als je Windows gebruikt krijgen alle applicaties toegang tot het hele systeem. what's your point MS?
Dat was onder Windows 98 het geval. Of je weet niet beter, of je bent aan het trollen.
Dat is nog steeds zo, Virussen hebben nog evenveel toegang tot je systeem als toen.
En als je er een OS naast installeert en die start, dan kan die zomaar bij de CPU komen! omg ohnoes! laten ze daar eerst eens wat aan doen!
ik draai gewoon een os waar userspace dat soort dingen helemaal niet kan en drivers gewoon bevijligd worden

deze drivers zorgen namelijk ook voor previlige escalation bug(admin worden zonder toestemming/wachtwoord)

ach jah zolang iedereen maar apt-get update& apt-get upgrade ( ik doe het elke dag)

ubuntu btw
ik draai gewoon een os waar userspace dat soort dingen helemaal niet kan en drivers gewoon bevijligd worden
Da's de theorie ja, maar jammer alleen dat er maar 1 buffer overflow in je userspace applicatie voor nodig is om aanvaller gezellig op rootrechten in je geheugen te laten rommelen.
Bovendien draaien videodrivers in Linux helemaal niet in userspace, maar hebben net zoals in OS X, iOS, Android en Windows gewoon directe hardware toegang.

[Reactie gewijzigd door Dreamvoid op 17 juni 2011 17:05]

[...]

Da's de theorie ja, maar jammer alleen dat er maar 1 buffer overflow in je userspace applicatie voor nodig is om aanvaller gezellig op rootrechten in je geheugen te laten rommelen.
Bovendien draaien videodrivers in Linux helemaal niet in userspace, maar hebben net zoals in OS X, iOS, Android en Windows gewoon directe hardware toegang.
Zover ik weet is dat niet mogelijk en moet je toch echt bevestigen met een venster.. en nog eens een password invoeren wil dat de programma of script oid root toegang krijgen...
Kijk met sudo vind ik het link want jouw passwoord is hetzelfde als de root... maar zowiezo gaat u verhaal hier niet op.

Met Windows zetten de meeste UAC uit en bestaat inderdaad het geval dat iemaand gewoon ok klikt zonder te kijken of dat de hacker zonder interactie administrator rechten krijgt... maar dat vind ik eigen schuld dikke bult

[Reactie gewijzigd door demilord op 18 juni 2011 01:38]

WebGL is niet onveilig. Developers hebben alleen toegang tot de grafische hardware omdat de onderliggende implementatie dat toestaat. Ofwel het driver-model van Microsoft is dus gewoon inherent onveilig of hun WebGL implementatie maakt het onveilig.
Zijn er uberhaupt mainstream OSsen waar de videodrivers *geen* directe hardware toegang hebben? Ik kan er geen bedenken. GNU/Linux, OS X, Android, Windows, alle console OSsen hebben applicaties allemaal close-to-the-metal toegang tot het videogeheugen. En het is niet alleen maar Windows waar dat exploitable is, kijk bv maar eens naar alle CoreImage/CoreVideo/QuartzExtreme security fixes op OS X, en alle console exploits. Het is in de praktijk onmogelijk gebleken om toegang tot video hardware goed af te schermen zonder de performance te schaden. En niemand wil tragere video performance dan de concurrent - je ziet aan Blackberry wat er gebeurt als je als enige een dichtgetimmerd OS met trage video performance levert, alle devs schreeuwen moord en brand en je wordt rap weggeconcurreerd.

[Reactie gewijzigd door Dreamvoid op 17 juni 2011 18:14]

Zijn er uberhaupt mainstream OSsen waar de videodrivers *geen* directe hardware toegang hebben? Ik kan er geen bedenken. GNU/Linux, OS X, Android, Windows, alle console OSsen hebben applicaties allemaal close-to-the-metal toegang tot het videogeheugen. En het is niet alleen maar Windows waar dat exploitable is, kijk bv maar eens naar alle CoreImage/CoreVideo/QuartzExtreme security fixes op OS X, en alle console exploits. Het is in de praktijk onmogelijk gebleken om toegang tot video hardware goed af te schermen zonder de performance te schaden. En niemand wil tragere video performance dan de concurrent - je ziet aan Blackberry wat er gebeurt als je als enige een dichtgetimmerd OS met trage video performance levert, alle devs schreeuwen moord en brand en je wordt rap weggeconcurreerd.
Inderdaad gebruikt Flash geen directe gpu toegang tot het renderen van flash
''Bijkomend probleem zou zijn dat de gemiddelde gebruiker niet gewend is zijn videokaartdrivers te upgraden, als er al nieuwe versies komen die de lekken dichten.''

Ik moet zeggen dat ze hiermee wel de spijker op hun kop slaan, stel je voor dat de integrated intel graphics een lek bevat. Dan heb je echt een probleem... bijna geen standaard gebruiker update zijn videokaart en automatisch gaat het niet.
Veel driver updates komen tegenwoordig gewoon binnen via Windows Update. Met name voor onboard chips, dus daar zie ik niet zoveel problemen. Op OSX gaan deze drivers ook met de updates mee en op Linux kun je ze ook vrij makkelijk up-to-date houden (alleen niet via de standaard updates, maar via een ander venster).
@Japs: I know, maar deze fabrikanten leven bijna geheel van OEM contracten, en PC bouwers (en OS leveranciers) willen stabiele en veilige systemen leveren. Ligt een videokaart leverancier te kloten met zijn drivers, dan is de exit-clausule van zo'n OEM contract gauw gevonden hoor ;). Dit lost zichzelf wel op.

[Reactie gewijzigd door Rick2910 op 17 juni 2011 15:38]

True, maar ik heb echt niet de illusie dat alle videokaartproducenten, voor al hun producten (oud en nieuw) braaf bij elke nieuwe lek een nieuwe gecertificeerde driver aanleveren...

Ik zie nu al geregeld opmerkingen langskomen van "producent X maakt beroerde drivers" of "producent Y is heel traag met bugfixes in de drivers". Terwijl deze producenten niet/nauwelijks rekening hebben hoeven te houden met kwaadwillenden...ze hoefden tot nu toe alleen te zorgen dat de drivers met de OS-en kunnen samenwerken (waarvoor ze bij de OS producenten kunnen aankloppen voor hulp/advies), en dat de games worden ondersteund (waarvoor ze bi jde game prodcucenten kunnen aankloppen).
De laatste keer dat ik een windows update deed stond er zelfs een driver voor mijn monitor bij. Ook voor mijn (onboard) geluidskaart heb ik wel eens een update gezien.

De opmerking van Microsoft valt duidelijk in de categorie FUD.

Wat ze goed begrepen hebben is dat geen mens ze geloofd als ze alleen maar zeggen dat hun product 'beter' is, dus komen ze met zo'n excuus.

De echte reden is natuurlijk dat direct3d alleen op windows werkt en "dus" goed is en webgl is ook op alternatieve (apple, linux) en 'dus' slecht (voor MicroSoft).
Je hebt het artikel echt niet gelezen of wel ?
Er wordt duidelijk aangegeven dat het hier gaat om problemen waar de software dus de browser niets mee kan doen om tegen te gaan. Webgl maakt een directe toegang tot de hardware mogelijk wat er voor zorgt dat alle veiligheid die Microsoft wil bieden in en door IE wegvalt. En natuurlijk willen ze liever dat mensen de eigen gemaakte optie kiezen maar dat is niet meer dan logisch.
Jij hebt mijn punt niet echt begrepen of wel?

Ze hebben al een windows update infrastructuur in-place. Net zoals linux dat heeft en apple dat heeft.

Of de patch nu ontwikkeld is door Microsoft of door Asus, of het nu een fix is voor een software- of een hardwareprobleem is Microsoft zou het kunnen uitrollen.

Microsoft geeft zelf aan of het een optionele instal is of dat het kritiek is. Ze kunnen het desnoods nog afdwingen ook (want zij hebben de infrastructuur).

Er is een marktvraag voor multiplatform en open standaard. Vandaar dat ze grafische hardwareversnelling het in de browser willen. Want dan maakt het niet meer uit of je een apple, red-hat of windows computer hebt, je hebt een html5 platform.

En aan die vraag voldoet microsoft niet door zijn voorstel van een windows-only eigen implementatie.

Willen ze veiligheid promoten laat ze dan meewerken aan het WebGL initiatief.

Apple , Google en Linux sluiten hier wel op aan, dus waarom is het logisch dat bedrijven liever hun eigen optie kiezen?
Of de patch nu ontwikkeld is door Microsoft of door Asus, of het nu een fix is voor een software- of een hardwareprobleem is Microsoft zou het kunnen uitrollen.

Microsoft geeft zelf aan of het een optionele instal is of dat het kritiek is. Ze kunnen het desnoods nog afdwingen ook (want zij hebben de infrastructuur).
Ik installeer zelf nooit de Microsoft aangeboden Videokaart updates. If it ain't broke don't fix it. Nieuwe drivers introduceren soms nieuwe features, die weer problemen geven met oudere spellen of oude videokaarten vertragen.

Tevens is Microsoft Update in deze slechts een "doorgeefluik" bij videokaart drivers. Ik verwacht dan ook nooit dat ze hem als Critical doorpushen, gezien dit niet door hun test straat heen gaat. Zelfs als ze dit als critical zouden doen, kom je met het probleem met verouderde videokaarten die niet ondersteund worden en dus Microsoft geen update kan leveren.

[Reactie gewijzigd door jordy5 op 17 juni 2011 17:27]

Drivers zijn optionele updates, ik durf te beweren dat 60% van de gebruikers die nooit installeert.
Bij mij worden standaard ook de optionele updates geinstalleerd als ik dat wil.
Aangezien dit meestal standaard ingesteld staat en de 'gemiddelde gebruiker' niet aan de instellingen zit word het meestal standaard geinstalleerd.
nieuwe drivers is leuk, maar als de videokaartfabrikant geen nieuwe drivers leverd waar het lek mee opgelost is heb je nog steeds een probleem..

EN nee, ze komen ook echt moet feiten waardoor WebGL een stuk minder veilig is.. Niets staat WebGL in de weg om daar dus zelf verbeteringen in aan te brengen..
Die drivers zijn optioneel en worden niet automatisch geinstaleerd.
De meeste mensen zullen dit ook niet doen.

Ook als MS deze driver updates zou pushen is het nog steeds niet veilig, het is bij dit soort dingen altijd achter de feiten aanlopen

[Reactie gewijzigd door Respawner op 17 juni 2011 16:21]

Het kan inderdaad gevaarlijk zijn als er geen abstractielaag tussen zit. Een abstractielaag zou ook het voordeel hebben dat security issues niet met driverupdates opgelost hoeven te worden, maar met browserupdates, en deze worden toch al min-of-meer opgedrongen.

Ik denk niet dat ik WebGL in deze hoedanigheid zou willen inschakelen op mijn systeem.
Ik ben het hier wel mee eens. Internet met alle bedreigingen van dien, moeten niet te veel toegang krijgen tot plekken die lekken bevatten. Alhoewel AV bedrijven weer een beetje extra bestaansrecht krijgen. Ze kunnen nu ook een soort van driverscan erin verwerken.

Software en drivers zullen foutlozer moeten zijn met deze ontwikkelingen.

Je zou als het ware een soort sandbox moeten kunnen maken die restricties oplegt aan de uitvoerbaarheden van WebGL met behulp van de videokaart. Weet niet of dit te realiseren is.

Tot die tijd zou deze 3d functie by default uit moeten staan en bij het inschakelen gecontroleerd moeten worden op videokaart updates o.i.d.
de vraag is ook op WebGL echt wel nodig is, performance is leuk, maar win9x hebben we net vaarwel gezegd omdat het toch handiger is om het boeltje stabiel te houden
webscripts die rechtstreeks drivers aanspreken lijkt mij dus een zeer slecht idee, zelf zonder slechte bedoelingen
Om nog maar te zwijgen over videokaarten waar de ondersteuning voor gestopt is! Nu zal dat op dit moment nog geen probleem vormen aangezien de kaarten die op dit moment al niet meer ondersteund worden geen WebGL support in de drivers hebben.

Maar in de toekomst zie ik daar ook zeker een probleem, drivers die wel WebGL support bevatten en te maken krijgen met exploits die niet meer gefixt gaan worden. Het probleem is inderdaad dat drivers amper bijgehouden worden door de gemiddelde gebruiker, wij Tweakers zullen daar niet snel mee te maken krijgen, echter betreft dat op het totaal maar een relatief kleine groep.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True