6 ms·

DOS vulnerability in Silverlight 5s 3D (similar to WebGL DOS vulnerability)

69 points by patrickaljord 15y ago

bjacob 15y ago
They closed my bug as "fixed" but didn't give any details. I'll have a look at it again when the next beta / final build of silverlight 5 comes out. In the WebGL WG we are very confident that this can't be fixed without working with GPU vendors on new robustness features in the drivers.
- kenjackson 15y ago
  This seems like an odd way to go about doing an open standard. Don't you usually want to let vendors work on getting things working and then come back and standardize based on best practices? It would seem like the WG should work with MS and Adobe to get Silverlight and Flash working really well. Get it out in peoples hands for a year or two. And then come back and say, "OK, we generally get 3D on the web now. Now lets standardize it." It really feels like this WG is in a race to hurry to get something out the door as fast as possible.
  - kkowalczyk 15y ago
    It seems to me the guy who reported the issue to Microsoft is doing the only thing that he can effectively do to help them. WebGL is a standard developed in an open way. If someone wants to contribute, including Microsoft, they can send an e-mail to a mailing list and that will reach other people working on WebGL and hopefully a productive conversation would ensue. Microsoft choose not to do that. Instead they issued a blanket statement to the whole world that WebGL is insecure. They made no effort to improve the security of WebGL and didn't leave any opening for the discussion. They just communicated a decision. Silverlight or IE engineers are not easily reachable and cannot be engaged in an open, technical dialogue the way WebGL folks can. The only venue that Microsoft provides to give feedback and bug reports is their connect website. This is the venue that Benoit used because it was the only venue available to him, as an individual. No one, including WebGL engineers, has special powers to engage Microsoft in discussion about their products. No one needs special powers to engage WebGL folks in discussion about WebGL. So you really have your power structure backwards. Notice also how this bug report is constructive: it shows a specific problem that Microsoft can fix. Notice how Microsoft's FUD wasn't constructive: they just labeled WebGL insecure using non-specific (therefore non-fixable) arguments.
    - tptacek 15y ago
      The only venue that Microsoft provides to give feedback and bug reports is their connect website. This is the venue that Benoit used because it was the only venue available to him, as an individual. That's not at all true, is it? http://www.microsoft.com/security/msrc/report.aspx http://www.microsoft.com/security/msrc/report.aspx
      - kkowalczyk 15y ago
        Nitpicking. Either way, usually using this way to report (what Microsoft claims) is a security bug would be more stand up way to do it but in this specific case, given Microsoft's FUD designed to kill WebGL (with the consequence of Flash and Silverlight having an upper hand wrt. 3d graphics in the browser), doing it publicly was the right call. It nicely shows Microsoft's double standards which is important to the overall discussion.
        tptacek 15y ago
        Google and Mozilla would not consider it "nitpicking" if I posted a security flaw to a public bug tracking site, then claimed "that's the only place to send them". All three of those vendors went out of their way to establish and communicate the method needed to safely publish security flaws in their products. The appearance of this report is that the reporter ignored that process out of spite. Is that the message the Web GL people are intending to send? I doubt it. Moreover, who's being punished here? Microsoft? Actions like this score PR points for Microsoft. It's users who pay the price of casual disclosure. I know that because that's what Google effectively says with their disclosure policy, and what Mozilla says with theirs. I think this was a bad call.
        nkassis 15y ago
        I don't get it, this software (Silverlight 5) is still in development. It's not meant to be used in production. If there is a flaw it should be reported. I would too have thought Microsoft Connect was the right place to report it. I don't see why it has to be hidden. ContextIS released their Firefox image stealing bug in public and it was quickly fixed by Mozilla within a week. I think this worked pretty well as far a security release goes. And this was for software already released to the public.
  - magicalist 15y ago
    why would you wait for microsoft or adobe to implement it? what you describe is exactly what has been happening for two years now, just with multiple browser makers working on independent experimental implementations.
- yuhong 15y ago
  Maybe it is the difference between Direct3D and OpenGL. I don't know enough to be sure, though.
  - corysama 15y ago
    The most common implementations of WebGL on Microsoft platforms are actually Direct3D wrappers under the hood.
    - yuhong 15y ago
      I know, I was referring to exactly whether OpenGL vs Direct3D is implementing WebGL.
- mmastrac 15y ago
  Could you explain how this particular example works?
  - bjacob 15y ago
    It just renders 10,000 rectangles of the size of the browser window, which by itself is enough to DOS; to make it a bit worse, it also uses a large texture and adresses it with very little respect for memory locality ;-) The C# code is here: http://people.mozilla.org/~bjacob/SilverLight5DOSJustLikeWebGL/HelloWorld3D/MainPage.xaml.cs http://people.mozilla.org/~bjacob/SilverLight5DOSJustLikeWeb... And the pixel shader: http://people.mozilla.org/~bjacob/SilverLight5DOSJustLikeWebGL/ShaderLibrary/Effects/Shaders/Color.ps.hlsl http://people.mozilla.org/~bjacob/SilverLight5DOSJustLikeWeb... EDIT: I forgot to mention that this is very similar to the WebGL DOS example, https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/extra/lots-of-polys-example.html https://cvs.khronos.org/svn/repos/registry/trunk/public/webg...
AshleysBrain 15y ago
Hehe... made me smile... but isn't this just Mozilla people winding up Microsoft? It makes a pretty big point of "just like WebGL". I doubt this will make Microsoft say "oh look they were right about WebGL, we'd better implement it now". Everyone knows Microsoft want to promote DirectX over OpenGL, and the legitimate-but-not-unsolvable security issues in WebGL serve as a nice excuse.
- mmastrac 15y ago
  This is more than just a wind-up: it shows that Microsoft can't attack WebGL on one hand and push Silverlight w/shaders on the other. This puts pressure on them to come up with a consistent message.
  - deleted 15y ago
    [deleted]
  - kenjackson 15y ago
    Except MS says this is fixed in SL.
  - bonch 15y ago
    Did any of the Microsoft-bashers here even read the article? Microsoft responds in the comments and says the issue is already fixed in internal builds and will ship with Silverlight 5 RTM.
kkowalczyk 15y ago
I'm glad that someone demonstrated Microsoft's FUD and their double-standards for security with a simple bit of code. Even if Microsoft fixes this particular issue, they either can't fix every possible variation or the same techniques that make this fixable can be used to fix it in WebGL. As long as you can send an arbitrary shader (which is essentially a small piece of executable code that GPU executes) to a GPU, you can overload the GPU. This capability is available in WebGL, Silverlight 5 and Flash. You don't want to remove this capability, because it's the core reason GPUs can do some things so much faster than a CPU. You can try to sanitize shaders as much as possible (and I'm sure both Silverlight and WebGL implementation will do their best) but it's not even theoretically possible to decide a time complexity of arbitrary assembly code. Writing code is about features vs. risk trade offs. Microsoft clearly has decided that the risks are acceptable for Silverlight but somehow the same category of risks is not acceptable for WebGL. And if you ask me, I agree with WebGL folks and the Silverlight part of Microsoft. The worst that can happen is slowing down your computer. This is an annoyance but also an issue we encounter daily: both my Mac and Windows software, including the OSes, crash and misbehave rather regularly. I accept that because the annoyance that it causes is much less important than my desire to use the software. It's also an annoyance that can be generated with technologies that already are part of the browser. A web page can exhaust any computer's memory (causing swapping) but sending arbitrarily large images. It's easy to write JavaScript that will eat CPU cycles. It's easy to DOS a browser by creating arbitrarily complex DOM and update it frequently enough. All those issues can be mitigated by browser implementors but none of them can really be fixed. And yet we happily use the internet and we'll happily keep using it after WebGL is implemented.
- daeken 15y ago
  From a security perspective, a shader-based DoS is annoying, but not a huge issue. Arbitrary code execution, potentially in the kernel, is. There are just too many moving pieces, too many un/poorly-tested components, and too little standing between a webpage and the kernel for my liking. While I want WebGL to become huge (I really dig it), from a security standpoint I simply can't support it in its current incarnation, and won't for a long while most likely. That said, these are not inherent design flaws, just realities of the stack it's on.
zandorg 15y ago
I read it as 'MS DOS' and thought it was backward-compatibility gone rogue.
- IvarTJ 15y ago
  It is surprising how excited people are with the IOS operating system.
bonch 15y ago
From the article: "DoS mitigations are implemented in current internal builds and will ship with Silverlight 5 RTM." - Microsoft This issue is already addressed. It's a non-issue being drummed up by Microsoft competitors. Even John Carmack agrees with Microsoft about WebGL.
- SigmundA 15y ago
  Then address it in WebGL in IE right? Or no just don't implement the standard...

69 points by patrickaljord 15y ago

They closed my bug as "fixed" but didn't give any details. I'll have a look at it again when the next beta / final build of silverlight 5 comes out. In the WebGL WG we are very confident that this can't be fixed without working with GPU vendors on new robustness features in the drivers.

kenjackson 15y ago
This seems like an odd way to go about doing an open standard. Don't you usually want to let vendors work on getting things working and then come back and standardize based on best practices? It would seem like the WG should work with MS and Adobe to get Silverlight and Flash working really well. Get it out in peoples hands for a year or two. And then come back and say, "OK, we generally get 3D on the web now. Now lets standardize it." It really feels like this WG is in a race to hurry to get something out the door as fast as possible.
- kkowalczyk 15y ago
  It seems to me the guy who reported the issue to Microsoft is doing the only thing that he can effectively do to help them. WebGL is a standard developed in an open way. If someone wants to contribute, including Microsoft, they can send an e-mail to a mailing list and that will reach other people working on WebGL and hopefully a productive conversation would ensue. Microsoft choose not to do that. Instead they issued a blanket statement to the whole world that WebGL is insecure. They made no effort to improve the security of WebGL and didn't leave any opening for the discussion. They just communicated a decision. Silverlight or IE engineers are not easily reachable and cannot be engaged in an open, technical dialogue the way WebGL folks can. The only venue that Microsoft provides to give feedback and bug reports is their connect website. This is the venue that Benoit used because it was the only venue available to him, as an individual. No one, including WebGL engineers, has special powers to engage Microsoft in discussion about their products. No one needs special powers to engage WebGL folks in discussion about WebGL. So you really have your power structure backwards. Notice also how this bug report is constructive: it shows a specific problem that Microsoft can fix. Notice how Microsoft's FUD wasn't constructive: they just labeled WebGL insecure using non-specific (therefore non-fixable) arguments.
  - tptacek 15y ago
    The only venue that Microsoft provides to give feedback and bug reports is their connect website. This is the venue that Benoit used because it was the only venue available to him, as an individual. That's not at all true, is it? http://www.microsoft.com/security/msrc/report.aspx http://www.microsoft.com/security/msrc/report.aspx
    - kkowalczyk 15y ago
      Nitpicking. Either way, usually using this way to report (what Microsoft claims) is a security bug would be more stand up way to do it but in this specific case, given Microsoft's FUD designed to kill WebGL (with the consequence of Flash and Silverlight having an upper hand wrt. 3d graphics in the browser), doing it publicly was the right call. It nicely shows Microsoft's double standards which is important to the overall discussion.
      - tptacek 15y ago
        Google and Mozilla would not consider it "nitpicking" if I posted a security flaw to a public bug tracking site, then claimed "that's the only place to send them". All three of those vendors went out of their way to establish and communicate the method needed to safely publish security flaws in their products. The appearance of this report is that the reporter ignored that process out of spite. Is that the message the Web GL people are intending to send? I doubt it. Moreover, who's being punished here? Microsoft? Actions like this score PR points for Microsoft. It's users who pay the price of casual disclosure. I know that because that's what Google effectively says with their disclosure policy, and what Mozilla says with theirs. I think this was a bad call.
        nkassis 15y ago
        I don't get it, this software (Silverlight 5) is still in development. It's not meant to be used in production. If there is a flaw it should be reported. I would too have thought Microsoft Connect was the right place to report it. I don't see why it has to be hidden. ContextIS released their Firefox image stealing bug in public and it was quickly fixed by Mozilla within a week. I think this worked pretty well as far a security release goes. And this was for software already released to the public.
- magicalist 15y ago
  why would you wait for microsoft or adobe to implement it? what you describe is exactly what has been happening for two years now, just with multiple browser makers working on independent experimental implementations.
yuhong 15y ago
Maybe it is the difference between Direct3D and OpenGL. I don't know enough to be sure, though.
- corysama 15y ago
  The most common implementations of WebGL on Microsoft platforms are actually Direct3D wrappers under the hood.
  - yuhong 15y ago
    I know, I was referring to exactly whether OpenGL vs Direct3D is implementing WebGL.
mmastrac 15y ago
Could you explain how this particular example works?
- bjacob 15y ago
  It just renders 10,000 rectangles of the size of the browser window, which by itself is enough to DOS; to make it a bit worse, it also uses a large texture and adresses it with very little respect for memory locality ;-) The C# code is here: http://people.mozilla.org/~bjacob/SilverLight5DOSJustLikeWebGL/HelloWorld3D/MainPage.xaml.cs http://people.mozilla.org/~bjacob/SilverLight5DOSJustLikeWeb... And the pixel shader: http://people.mozilla.org/~bjacob/SilverLight5DOSJustLikeWebGL/ShaderLibrary/Effects/Shaders/Color.ps.hlsl http://people.mozilla.org/~bjacob/SilverLight5DOSJustLikeWeb... EDIT: I forgot to mention that this is very similar to the WebGL DOS example, https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/extra/lots-of-polys-example.html https://cvs.khronos.org/svn/repos/registry/trunk/public/webg...

AshleysBrain 15y ago

Hehe... made me smile... but isn't this just Mozilla people winding up Microsoft? It makes a pretty big point of "just like WebGL". I doubt this will make Microsoft say "oh look they were right about WebGL, we'd better implement it now". Everyone knows Microsoft want to promote DirectX over OpenGL, and the legitimate-but-not-unsolvable security issues in WebGL serve as a nice excuse.

mmastrac 15y ago
This is more than just a wind-up: it shows that Microsoft can't attack WebGL on one hand and push Silverlight w/shaders on the other. This puts pressure on them to come up with a consistent message.
- deleted 15y ago
  [deleted]
- kenjackson 15y ago
  Except MS says this is fixed in SL.
- bonch 15y ago
  Did any of the Microsoft-bashers here even read the article? Microsoft responds in the comments and says the issue is already fixed in internal builds and will ship with Silverlight 5 RTM.

kkowalczyk 15y ago

I'm glad that someone demonstrated Microsoft's FUD and their double-standards for security with a simple bit of code. Even if Microsoft fixes this particular issue, they either can't fix every possible variation or the same techniques that make this fixable can be used to fix it in WebGL. As long as you can send an arbitrary shader (which is essentially a small piece of executable code that GPU executes) to a GPU, you can overload the GPU. This capability is available in WebGL, Silverlight 5 and Flash. You don't want to remove this capability, because it's the core reason GPUs can do some things so much faster than a CPU. You can try to sanitize shaders as much as possible (and I'm sure both Silverlight and WebGL implementation will do their best) but it's not even theoretically possible to decide a time complexity of arbitrary assembly code. Writing code is about features vs. risk trade offs. Microsoft clearly has decided that the risks are acceptable for Silverlight but somehow the same category of risks is not acceptable for WebGL. And if you ask me, I agree with WebGL folks and the Silverlight part of Microsoft. The worst that can happen is slowing down your computer. This is an annoyance but also an issue we encounter daily: both my Mac and Windows software, including the OSes, crash and misbehave rather regularly. I accept that because the annoyance that it causes is much less important than my desire to use the software. It's also an annoyance that can be generated with technologies that already are part of the browser. A web page can exhaust any computer's memory (causing swapping) but sending arbitrarily large images. It's easy to write JavaScript that will eat CPU cycles. It's easy to DOS a browser by creating arbitrarily complex DOM and update it frequently enough. All those issues can be mitigated by browser implementors but none of them can really be fixed. And yet we happily use the internet and we'll happily keep using it after WebGL is implemented.

daeken 15y ago
From a security perspective, a shader-based DoS is annoying, but not a huge issue. Arbitrary code execution, potentially in the kernel, is. There are just too many moving pieces, too many un/poorly-tested components, and too little standing between a webpage and the kernel for my liking. While I want WebGL to become huge (I really dig it), from a security standpoint I simply can't support it in its current incarnation, and won't for a long while most likely. That said, these are not inherent design flaws, just realities of the stack it's on.

zandorg 15y ago

I read it as 'MS DOS' and thought it was backward-compatibility gone rogue.

IvarTJ 15y ago
It is surprising how excited people are with the IOS operating system.

bonch 15y ago

From the article: "DoS mitigations are implemented in current internal builds and will ship with Silverlight 5 RTM." - Microsoft This issue is already addressed. It's a non-issue being drummed up by Microsoft competitors. Even John Carmack agrees with Microsoft about WebGL.

SigmundA 15y ago
Then address it in WebGL in IE right? Or no just don't implement the standard...