WebGL: What's the worst that could happen?

[Rakehellion]

What are some examples of malicious code someone could potentially run in a browser using WebGL? Of course you could create an infinite loop and send the user's cursor grinding to a halt, but are there more clever tricks hackers could implement? Memory injection? Arbitrary code on the CPU?

 

[BrightCandle]

If it was a current exploit then it would be legally and certainly morally dodgy to provide an example of malicious code. No one with that knowledge who is on the right side of the law would share such a thing with you.

 

[Cogman]

If it was a current exploit then it would be legally and certainly morally dodgy to provide an example of malicious code. No one with that knowledge who is on the right side of the law would share such a thing with you.

eh? The security community does that sort of thing all the time. In most recent history both heartbleed and shellshock had POCs code publicly available the day the exploits were made known.

Here is one such example

http://blog.beyondtrust.com/exploiting-ms14-059-because-sometimes-xss-is-fun-sometimes

It does depend on the security researcher, but by and large I think most believe that showing the exploit in action is the best way to show its potential impact and to get the issue fixed. Sure, some will share first with the company and then wait a week to share with the world, but many share immediately to raise public awareness.

 

[Rakehellion]

If it was a current exploit then it would be legally and certainly morally dodgy to provide an example of malicious code. No one with that knowledge who is on the right side of the law would share such a thing with you.

This is a programming forum, that's exactly the sort of thing we share here.

 

[BrightCandle]

The way this is meant to work is the exploit is found by a white hat, they tell the developers of the exploit who fix it (there is usually a private way for open source communities so its limited to a few developers) and then once the fix is out the exploit is publicised. If you do anything else there is definitely a chance of going to jail. That is how this works, which is why exploits are not shared on sites like this, because that would be sharing exploits which is basically illegal in a lot of countries these days.

I don't disagree that is ridiculous, just tell you why you wont get security experts telling you about current exploits that can still be exploited.

 

[brianmanahan]

it could be as bad as VRML

 

[Rakehellion]

The way this is meant to work is the exploit is found by a white hat, they tell the developers of the exploit who fix it (there is usually a private way for open source communities so its limited to a few developers) and then once the fix is out the exploit is publicised. If you do anything else there is definitely a chance of going to jail. That is how this works, which is why exploits are not shared on sites like this, because that would be sharing exploits which is basically illegal in a lot of countries these days.

I don't disagree that is ridiculous, just tell you why you wont get security experts telling you about current exploits that can still be exploited.

Sharing bits of code isn't remotely the same thing as telling someone to go to site X and do Y.

 

[Rakehellion]

it could be as bad as VRML

I remember that one. I loved it.

 

[Spungo]

If it was a current exploit then it would be legally and certainly morally dodgy to provide an example of malicious code. No one with that knowledge who is on the right side of the law would share such a thing with you.

I think he means general terms, not specific code.

Here's a generic example:

That comic doesn't give exact instructions for destroying something, but it gives a vague idea of how such an attack works. You can't prevent problems if you don't know they exist or how they work on a conceptual level.

 

[brandonb]

Note: I know nothing about WebGL, almost nothing about OpenGL, and know a lot more about DirectX.

But that said. Someone who was intentionally trying to cause some harm would probably find an easy time exploiting the system. I know of certain things I can do which will cause the Video Card/Computer to lock up for example in DirectX.

 

[uclabachelor]

Note: I know nothing about WebGL, almost nothing about OpenGL, and know a lot more about DirectX.

But that said. Someone who was intentionally trying to cause some harm would probably find an easy time exploiting the system. I know of certain things I can do which will cause the Video Card/Computer to lock up for example in DirectX.

The worse? Utilizing an exploit that allows arbitrary commands to execute on the client OS, allowing the hacker to do anything.

 

[brianmanahan]

I remember that one. I loved it.

i still have my VRML book from '96 on my shelf, lol

 

[Markbnj]

Note: I know nothing about WebGL, almost nothing about OpenGL, and know a lot more about DirectX.

But that said. Someone who was intentionally trying to cause some harm would probably find an easy time exploiting the system. I know of certain things I can do which will cause the Video Card/Computer to lock up for example in DirectX.

Well WebGL has no access to the hardware functions... in theory. It runs in a browser sandbox like javascript. But the question is really too broad to answer anyway. The WebGL API might be exploitable in some ways due to design or implementation issues, like any other API and implementation. The only way to say what exploits there are and what they can do is to find them.

 

[Cogman]

Well WebGL has no access to the hardware functions... in theory. It runs in a browser sandbox like javascript. But the question is really too broad to answer anyway. The WebGL API might be exploitable in some ways due to design or implementation issues, like any other API and implementation. The only way to say what exploits there are and what they can do is to find them.

Yup. And those exploits aren't likely to live long. Browsers have gotten ridiculously fast at fixing security issues and getting that fix deployed everywhere. This is mostly out of necessity. Browsers are one of the quickest and easiest ways for a computers to be compromised, so they really don't mess around when it comes to security.

 

[Rakehellion]

The worse? Utilizing an exploit that allows arbitrary commands to execute on the client OS, allowing the hacker to do anything.

Yeah, I'm wondering if such an attack exists. Video drivers aren't really guarded against malicious code, are they?

Obviously you can lock up the client's screen if the browser doesn't have safeguards against this.

 

[Markbnj]

Yeah, I'm wondering if such an attack exists. Video drivers aren't really guarded against malicious code, are they?

Yes, as a general rule they are. They run in the kernel namespace at or close to the highest level of privilege, are usually signed, and in most modern systems there are separate operating system routines watching the code modules in those namespaces to guard against code injection. A driver author could certainly corrupt a signed driver, but otherwise that is not so common. You might be thinking of code that runs on the GPU itself, such as shaders or cuda programs. I am not expert enough to know how that stuff is sandboxed, but I'm pretty sure it doesn't have the capability of breaking back out into the hose system and addressing memory or registers.

 

[Cogman]

Yes, as a general rule they are. They run in the kernel namespace at or close to the highest level of privilege, are usually signed, and in most modern systems there are separate operating system routines watching the code modules in those namespaces to guard against code injection. A driver author could certainly corrupt a signed driver, but otherwise that is not so common. You might be thinking of code that runs on the GPU itself, such as shaders or cuda programs. I am not expert enough to know how that stuff is sandboxed, but I'm pretty sure it doesn't have the capability of breaking back out into the hose system and addressing memory or registers.

I could see memory vulnerabilities, mostly because the video card has DMA access which gives it free rein to read or write wherever it likes. However, those would probably be pretty rare and card/driver dependent. That would make it pretty hard to exploit.

My bet is that most if not all video cards suffer from use after free vulnerabilities though. From what I've read, those are some of the harder find and most pernicious vulnerabilities in current browser.

 

[Rakehellion]

Yes, as a general rule they are. They run in the kernel namespace at or close to the highest level of privilege, are usually signed, and in most modern systems there are separate operating system routines watching the code modules in those namespaces to guard against code injection. A driver author could certainly corrupt a signed driver, but otherwise that is not so common. You might be thinking of code that runs on the GPU itself, such as shaders or cuda programs. I am not expert enough to know how that stuff is sandboxed, but I'm pretty sure it doesn't have the capability of breaking back out into the hose system and addressing memory or registers.

You do write shaders for WebGL.

 

[Rakehellion]

I think he means general terms, not specific code.

Here's a generic example:

That comic doesn't give exact instructions for destroying something, but it gives a vague idea of how such an attack works. You can't prevent problems if you don't know they exist or how they work on a conceptual level.

Someone actually tried that one a while ago. http://arstechnica.com/tech-policy/2014/09/swedish-voter-uses-javascript-code-as-write-in-candidate/