4 ms·

Any updates on the security of NaCl? Every time that sort of thing has been tried, it has been a total failure from a security standpoint, and I haven't yet se

by amalcon 16y ago

Any updates on the security of NaCl? Every time that sort of thing has been tried, it has been a total failure from a security standpoint, and I haven't yet seen reason for NaCl to be any different.

Pengwin 16y ago
I've never been aware of NaCl, but when I just read what it was, I was filled with the exact same sentiment. Isn't this what ActiveX was all about? We all know what happened in that instance.
- prodigal_erik 16y ago
  ActiveX never had a sandbox. They didn't even try to safely run untrusted binaries. "Safe for scripting" merely meant the author claimed the control was designed not to do horrible things to your system even if invoked by a malicious script on a web page.
ary 16y ago
This was my first concern followed by, "wait, Chrome silently auto-updates..." As far as I know it silently auto-updates across major versions as well as minor. The automatic updating of Flash 10.x that got linked on HN a little while ago is a great example of how this is good. A widely publicized hole in Native Client could turn it on its head quickly. It's a gut reaction on my part, but distributing Native Client to Chrome's user-base feels premature. It's only been an acknowledged project at Google for what, less than two years? I recall hearing about it at I/O 2009, and I'd wish they'd let it bake a while longer.
EricBurnett 16y ago
They are certainly trying to make it as secure as possible. It is open source, they've held at least one contest to try to break the security of it (http://code.google.com/contests/nativeclient-security/faq.html http://code.google.com/contests/nativeclient-security/faq.ht...), it is running inside a sandbox with limited permissions, etc. While it is always risky to introduce anything new, that is a price we pay for progress. And that is true for anything - at this point, I don't think using it would be too much more risky than using a new javascript engine, for example. Aside from never trying anything new, what else can we hope for? Also, I will point out that even in the dev channel it is still disabled by default. So there is some time yet for the security to be evaluated, to see if there are any endemic problems.
werrett 16y ago
Security has been a focus of NaCl from the outset. It uses a sandbox security model built around a restricted set of "native code". The aim was to make NaCl apps verifiable from a security stand point. Chris Rohlf from Matasano did a great blog post, The Security Implications Of Google Native Client, that compares the NaCl approach to ActiveX and Java -- and included beautiful diagrams to boot! Unfortunately the images appear to be broken on the Matasano blog [1] but I've found a PDF'd version [2] that contains them in all their glory. The post came out of the Matasano team's entry in the Native Client Security Contest [3] that Google held early last year. The Matasano team ended up taking second place behind Mark Dowd / Ben Hawkes [4]. All those guys are 'rockstars' in the security industry. So, Google has thought deeply and tried hard when designing NaCl's security. They a care enough and are switched on enough to run a security contest that was well received by the industry (rare). A number of mega-brains-on-sticks found issues back in May '09 -- hopefully they have all been addressed. It looks to me that Google has done a good job at learning from past mistakes when implementing NaCl and it should be different. No doubt there will be further security issues found but then again, name a framework that is free from flaws? [1] http://chargen.matasano.com/chargen/2009/8/27/the-security-implications-of-google-native-client.html http://chargen.matasano.com/chargen/2009/8/27/the-security-i... [2] http://beefchunk.com/documentation/security/the_security_implications_of_google_native_client.pdf http://beefchunk.com/documentation/security/the_security_imp... [3] http://code.google.com/contests/nativeclient-security/index-old.html http://code.google.com/contests/nativeclient-security/index-... [4] http://code.google.com/contests/nativeclient-security/index.html http://code.google.com/contests/nativeclient-security/index....
barrkel 16y ago
Can you point to a similar thing? I personally haven't seen it: binary proving of a limited subset of the x86 instruction set.

by amalcon 16y ago

Any updates on the security of NaCl? Every time that sort of thing has been tried, it has been a total failure from a security standpoint, and I haven't yet seen reason for NaCl to be any different.

Pengwin 16y ago

I've never been aware of NaCl, but when I just read what it was, I was filled with the exact same sentiment. Isn't this what ActiveX was all about? We all know what happened in that instance.

prodigal_erik 16y ago
ActiveX never had a sandbox. They didn't even try to safely run untrusted binaries. "Safe for scripting" merely meant the author claimed the control was designed not to do horrible things to your system even if invoked by a malicious script on a web page.

ary 16y ago

This was my first concern followed by, "wait, Chrome silently auto-updates..." As far as I know it silently auto-updates across major versions as well as minor. The automatic updating of Flash 10.x that got linked on HN a little while ago is a great example of how this is good. A widely publicized hole in Native Client could turn it on its head quickly. It's a gut reaction on my part, but distributing Native Client to Chrome's user-base feels premature. It's only been an acknowledged project at Google for what, less than two years? I recall hearing about it at I/O 2009, and I'd wish they'd let it bake a while longer.

EricBurnett 16y ago

They are certainly trying to make it as secure as possible. It is open source, they've held at least one contest to try to break the security of it (http://code.google.com/contests/nativeclient-security/faq.html http://code.google.com/contests/nativeclient-security/faq.ht...), it is running inside a sandbox with limited permissions, etc. While it is always risky to introduce anything new, that is a price we pay for progress. And that is true for anything - at this point, I don't think using it would be too much more risky than using a new javascript engine, for example. Aside from never trying anything new, what else can we hope for? Also, I will point out that even in the dev channel it is still disabled by default. So there is some time yet for the security to be evaluated, to see if there are any endemic problems.

werrett 16y ago

Security has been a focus of NaCl from the outset. It uses a sandbox security model built around a restricted set of "native code". The aim was to make NaCl apps verifiable from a security stand point. Chris Rohlf from Matasano did a great blog post, The Security Implications Of Google Native Client, that compares the NaCl approach to ActiveX and Java -- and included beautiful diagrams to boot! Unfortunately the images appear to be broken on the Matasano blog [1] but I've found a PDF'd version [2] that contains them in all their glory. The post came out of the Matasano team's entry in the Native Client Security Contest [3] that Google held early last year. The Matasano team ended up taking second place behind Mark Dowd / Ben Hawkes [4]. All those guys are 'rockstars' in the security industry. So, Google has thought deeply and tried hard when designing NaCl's security. They a care enough and are switched on enough to run a security contest that was well received by the industry (rare). A number of mega-brains-on-sticks found issues back in May '09 -- hopefully they have all been addressed. It looks to me that Google has done a good job at learning from past mistakes when implementing NaCl and it should be different. No doubt there will be further security issues found but then again, name a framework that is free from flaws? [1] http://chargen.matasano.com/chargen/2009/8/27/the-security-implications-of-google-native-client.html http://chargen.matasano.com/chargen/2009/8/27/the-security-i... [2] http://beefchunk.com/documentation/security/the_security_implications_of_google_native_client.pdf http://beefchunk.com/documentation/security/the_security_imp... [3] http://code.google.com/contests/nativeclient-security/index-old.html http://code.google.com/contests/nativeclient-security/index-... [4] http://code.google.com/contests/nativeclient-security/index.html http://code.google.com/contests/nativeclient-security/index....

barrkel 16y ago

Can you point to a similar thing? I personally haven't seen it: binary proving of a limited subset of the x86 instruction set.