The Disturbing Results With Automated Fuzzing Of OpenGL Shaders

[mlau]

How many of this bugs are valid OpenGL shader? I remember following the bug report for the mesa driver, It turns out that the shader was invalid, it was using a inout parameter when it shouldn't or something like that.

So I wonder how many of them should be a turn to compilation error instead of silently fail and misrender

I only looked at the image on the front page of the article, but they all seem to be more or less no ops. Inserted into a valid shader they should actually not
affect the shader at all.

[microcode]

How many of this bugs are valid OpenGL shader? I remember following the bug report for the mesa driver, It turns out that the shader was invalid, it was using a inout parameter when it shouldn't or something like that.

So I wonder how many of them should be a turn to compilation error instead of silently fail and misrender

The ones shown on that page are completely valid. The bugs are triggered by inserting code that should be inert.

[microcode]

I'm not even surprised. I have been able to restart whole iPhones and crash Mac browsers with WebGL by accident, during normal development activity.

I'm working on a SPIR-V canonicalizer, and I'm considering releasing it to the public domain to encourage vendors to integrate it. So much can go wrong, even when parsing the simplest formats: from denial of service to arbitrary execution.

[shmerl]

Well, it seems one can buy the tool . They say that - i.e. the usual nonsense that obscurity somehow implies more security.

Indeed. A lame excuse for not open sourcing the tool. If hackers can find bugs, so can driver developers who can fix them sooner.

[andrei_me]

mlau microcode

Found the original bug report, but the issue that I commented turned to be an issue on the original shader that they started to fuzz with, not that the fuzzing generated the issue.

So the issues that they found are probably correct.

https://bugs.freedesktop.org/show_bug.cgi?id=99919

[slacka]

The problem here is that being closed and/or being behind a paywall are NOT really an issue for a hacker that might be interested to these kinds of vulns.

People still think hackers are bored broke kids, but they are not.

This is not Amazon, 1-click order here. The author wants you to contact him. How do you know there isn't an extensive vetting system and he's doing the right thing by trying to reach driver developers first?

[L_A_G]

No, it should be used by as many people as possible to discover 0-days and then *those discoveries* should be kept under wraps for some time until it's fixed. By making this closed and secret you're giving hackers all the power to do this fuzzing manually, and the good guys no chance to find the exploits and fix their software in time unless they all reimplement this fuzzer (or buy the tool).

The only problem with this is that it assumes everyone who gets their hands on the tool will stick to keeping the vulnerabilities between them and the affected vendors, which is highly unlikely, as well as assuming that any attackers won't use the tool to speed up their discovery of vulnerabilities.

This obviously is a situation where you have to weigh the pros against the cons, but I'd say that the pros and cons of keeping this out of the hands of attackers and just regular assholes who use it to find vulnerabilities they can publish with no heads-up time for affected vendors outweighs the pros and cons of letting everyone and their dog have access to this exploit discovery tool.

The problem here is that being closed and/or being behind a paywall are NOT really an issue for a hacker that might be interested to these kinds of vulns.

People still think hackers are bored broke kids, but they are not. We are talking of people that make malware SDKs that are sold for 2k dollars apiece (on the black market anyway) so they ain't broke, and people that almost always work with pre-compiled binaries so they have experience with decompiling or getting info out of binaries.

The issue here is not them asking money for the tool, but controlling who gets access to it. They're obviously not going to give access to anyone with the money so your argument here is quite clearly a straw man (which probably goes without saying the way you act like my idea of what kinds of people malware developers are is stuck in the 1980s). If they release it as open source then everyone, both ethical hackers and the less-than-ethical crowd will have unrestricted access to the tool.

[R41N3R]

I'm not even surprised. I have been able to restart whole iPhones and crash Mac browsers with WebGL by accident, during normal development activity.

I'm working on a SPIR-V canonicalizer, and I'm considering releasing it to the public domain to encourage vendors to integrate it. So much can go wrong, even when parsing the simplest formats: from denial of service to arbitrary execution.

I think graphic driver crashes are not uncommon on Linux as well... Enabling in Firefox e.g. the OpenGL hardware acceleration or Webrender can trigger a crash, several games or OpenGL accelerated desktops like Plasma (especially on Wayland) have the issue as well to cause a complete system freeze. To use it in an exploit is maybe another topic, but Linux graphic drivers have often enough crashed my complete system. Therefore I think closed bugs based on a proprietary software are welcome as well, sure it should be open source, but the developer cannot be forced to change the license.

[microcode]

I think graphic driver crashes are not uncommon on Linux as well... Enabling in Firefox e.g. the OpenGL hardware acceleration or Webrender can trigger a crash, several games or OpenGL accelerated desktops like Plasma (especially on Wayland) have the issue as well to cause a complete system freeze. To use it in an exploit is maybe another topic, but Linux graphic drivers have often enough crashed my complete system. Therefore I think closed bugs based on a proprietary software are welcome as well, sure it should be open source, but the developer cannot be forced to change the license.

What driver are you talking about? The NVIDIA one? Catalyst? Because those are the same drivers the author of this paper is testing on Windows. I've never experienced a crash with a stable release of Mesa while running a standard application, not even back in the day. Then again, maybe there's something new about plasma on Wayland. I've been running Servo nightlies though, so I guess you're not talking about i965 or RadeonSI.