

Results of the Google Native Client security contest - mark_h
http://googlecode.blogspot.com/2009/07/native-client-security-contest-results.html

======
ShabbyDoo
Let's presume that the world can be convinced of the safety of native client
security. What's it worth? I think this is the same question as, "What kinds
of things aren't good enough on the JVM or CLR?"

Modeling/Simulation/etc. certainly benefits from running on the metal. But,
with the exception of SETI@Home, etc., nobody runs untrusted simulation code.
Games are the obvious target. A webby sort of Photoshop might also benefit.
What else?

Am I wrong to think it obvious that Google's goal is to do away with the last
major reason(s) to run Windows? Is there any other benefit to being so close
to the metal when we have nice, sandboxed VMs that JIT compile quite efficient
code?

~~~
wmf
Previous discussion of this topic:
<http://news.ycombinator.com/item?id=390555>

My arguments for NaCl:

1\. Rewriting C code in Java is expensive.

2\. JITs do a poor job on SIMD code that is used in multimedia.

------
ajg1977
"Nothing that pointed to a fundamental flaw in the design of Native Client".

No, just many flaws in the implementation that allowed unverified code to be
run and make sys calls.

Seems like quite a disingenuous statement.

~~~
tptacek
You'd rather they make or dispose of an undecidable claim? Everything has
implementation flaws. They're right; nobody came up with a way to beat the
simplified, scrubbed x86 subset they came up with to run NaCL in.

~~~
crux_
Well, they found places where it ran more than the purported subset:

> In the contest build, there were instruction sequences found that could
> jailbreak you from the sandbox.

From this link, which is fascinating & thoughtful on the topic:

[http://www.matasano.com/log/1674/the-security-
implications-o...](http://www.matasano.com/log/1674/the-security-implications-
of-google-native-client/)

~~~
tptacek
Thanks, we worked hard on that post.

The vulnerability you're talking about is a straightforward implementation
flaw. Admittedly, it's a flaw NaCL's design begs you to make: forgetting about
an aspect of x86 encoding is a problem you only have if you're going to let
raw x86 instructions hit the processor. But the fix for it is no harder than
the fix for, say, an implementation fault in the ELF loader code.

~~~
crux_
Hah, well, as you authored it you know what it says better than I! :)

But I'm inclined to say that "they're at greater risk of implementation flaws
because of their design" -- and unlike you, for me I believe that itself does
actually count as a design flaw.

(And on a side topic/rant since you mention the ELF loader: were I to have
Google's resources, I would be far more paranoid than they about this whole
thing. e.g.: the ELF loader doesn't need to be fantastically speedy; why not
write it using tools/languages with stronger guarantees of memory safety?
(That would hold for anything that wasn't inner-loop stuff, as well.)

Another example: The verifier & safety of the allowed instructions are the
crown jewels; why not hire the pointy-headed folks who do formal verification
for some stronger assurances that the allowed instructions really are safe and
that the verifier is complete?)

Edit to add: And if changing the language & tooling isn't feasible, they could
have at least pulled a neat trick and run the ELF loader (and similarly
exposed code) within their own sandbox, rather than outside of it.

------
tumult
I really hope this goes somewhere. I think there's a good chance they'll be
able to make it difficult to attack this client to the point that other
targets (Flash, Java, QuickTime, etc) will be easier to do damage with. And
native code in the browser would rock, obviously.

------
brown9-2
Funny timing, this article about Dowd just peaked last night:
<http://news.ycombinator.com/item?id=690592>

