3 ms·

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 fr

by crux_ 17y ago

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-of-google-native-client/ http://www.matasano.com/log/1674/the-security-implications-o...

tptacek 17y ago
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_ 17y ago
  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.

by crux_ 17y ago

tptacek 17y ago

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_ 17y ago
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.