

DOS vulnerability in Silverlight 5s 3D (similar to WebGL DOS vulnerability) - patrickaljord
http://connect.microsoft.com/VisualStudio/feedback/details/676134/dos-vulnerability-in-silverlight-5s-3d-similar-to-webgl-dos-vulnerability

======
kkowalczyk
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
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.

~~~
magicalist
shaders are not arbitrary code nor are they executed in the kernel. the same
goes with API calls. while opening APIs to new parts of a system always
exposes new risks, specious reasoning is not sufficient to determine if the
risks are manageable and mitigable.

notice that khronos and the webgl implementers have not responded with
content-less dismissals of these concerns. they have outlined the exact steps
they've taken to secure their API from the limits of the GPU model _and_ their
work to prevent buggy GPUs/drivers from executing webgl content at all. If
someone can actually demonstrate (or even speculate on a mechanism of action
of) an actual attack that isn't addressed by their current systems or (in the
case of DoS attacks) their ongoing work with OS and GPU vendors, _then_ we can
talk about fundamentally flawed. Until then it's a matter of risk assessment.

~~~
daeken
I never said that shaders are arbitrary code or that they're executed in the
kernel. WebGL in general opens up a huge attack surface, however, much of
which _is_ in the kernel. As soon as WebGL hit Webkit, I started testing it
for two reasons: 1) I do 3d art, and 2) I work in security. I understand the
systems involved quite well, and I'm still very concerned about it.

------
bjacob
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
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
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
_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>

~~~
yuhong
MSRC is generally used to report security bugs for released products only.
They do now patch some prerelease products, though.

~~~
marshray
Microsoft even started a branch for researching (and methodically disclosing)
bugs in _other_ vendors products.

<https://twitter.com/k8em0/status/83302574681374721>

This makes sense when you think about it. They likely get the crash dumps from
Mozilla's beta testers too. They definitely have a better handle on
determining their exploitability.

Nobody has more experience with video driver bugs than Microsoft.

------
AshleysBrain
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
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.

~~~
kenjackson
Except MS says this is fixed in SL.

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

~~~
IvarTJ
It is surprising how excited people are with the IOS operating system.

------
bonch
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
Then address it in WebGL in IE right? Or no just don't implement the
standard...

