Google NativeClient Security Contest 175
An anonymous reader writes "You may remember Google's NativeClient project, discussed here last December. Don't be fooled into calling this ActiveX 2.0 — rather than a model of trust and authentication, NaCl is designed to make dangerous code impossible by enforcing a set of a rules at load time that guarantee hostile code simply cannot execute (PDF). NaCl is still in heavy development, but the developers want to encourage low-level security experts to take a look at their design and code. To this end Google has opened the NativeClient Security Contest, and will award prizes topping out at $2^13 to top bug submitters. If you're familiar with low level security, memory segmentation, accurate disassembly of hostile code, code alignment, and related topics, do take a look. Mac, Linux, and Windows are all supported."
NaCl? (Score:2, Insightful)
Who else was confused how Salt was going to help software security?
I shook my head and said What??? as I read it for the third time to realize that they simply have a poorly chosen acronym
x86 in the browser? Ugh... (Score:5, Insightful)
dangerous code impossible? (Score:5, Insightful)
I doubt that. More likely they intend to make its detection and negation easier.
After all, the best language man can devise can only work as well as the coders who utilise it. If they are forced to cut corners in order to meet deadlines, errors will creep in, and we all know the urge to be first to profit is a prime reason for such things.
Proofs are only as good as the implementation. (Score:5, Insightful)
Beware of bugs in the above code; I have only proved it correct, not tried it.
- Knuth
Re:dangerous code impossible? (Score:5, Insightful)
Nope. NaCl is designed to be secure, read the PDF (I read it some time ago).
It's not really that hard, VMWare/VBox does something like this for 10 years now.
There might be some subtle race condition bugs, but so far it looks very well thought out.
This is like the opening of a monster movie (Score:4, Insightful)
where the scientist is saying he's covered all the bases, and nothing can go wrong.
Re:gee - sounds exactly like... (Score:3, Insightful)
Is .NET open source?
Has .NET been vetted by experts in the way open source projects like this will be?
Is .NET likely to ever be cross platform?
Is .NET for running x86 code?
Now I'm no expert and could be way off base but there seem to be some pretty major differences here....
2^13? (Score:5, Insightful)
Admittedly, it's after past 1AM, so maybe my maths stopped working by now, but isn't 2^13 about 8000 dollars for the grand prize? It seems a bit low for all the work of basically reviewing their code and concepts.
Hostile code disassembly? If it were that simple to disassemble someone else's code and automatically prove that it can't do anything wrong -- including by having security holes exploitable by a third party -- forget the browser, we'd have it standard in the OS or in the last step of make/ant/whatever. We could all stop worrying about antiviruses (who, in turn, would stop needing signatures and heuristics updated all the time anyway), reviewing code by hand to see if all buffers are checked, etc. Just run the magic utility and it'll tell you.
I'm willing to bet that at least the antivirus makers have tried that before, you know, what with all of them offering some forms of heuristics by now, and none of them got it past the level of hit-and-miss. More miss than hit, in fact.
Not saying that Google couldn't have got some genius that actually made it work, but at the very least it's not going to be a trivial job digging through all their cases to check if they really checked all possible attack vectors.
And 8192 dollars doesn't really seem to be much incentive for doing that work.
Re:2^13? (Score:4, Insightful)
NaCl just does not check that there's no buffer overflows, instead it isolates the program to make sure that buffer overflows do not cause problems.
I.e. you can can overflow, use dangling pointers and cause all sorts of access violations to your heart's contents inside the NaCl sandbox. But it won't cause a security breach.
Re:This is like the opening of a monster movie (Score:3, Insightful)
Re:2^13? (Score:3, Insightful)
Re:Guarantee hostile code cannot execute (Score:3, Insightful)
Of course, Windows didn't have memory protection until Windows NT (1993), and Macs until MacOS X (2001). http://en.wikipedia.org/wiki/Memory_protection [wikipedia.org]
Re:It made me cackle too (Score:1, Insightful)
Not necessarily two anions. You just need enough to balance things out. Since Calcium is an alkaline metal, it has two valance electrons in its outer energy level and chlorine, as a halogen, has seven. Since the two react to form an ionic compound, the outer energy levels for each element need to be full. In this case that results in CaCl2, but it could also result in CaO, for instance, which does not consist of two anions.
Re:x86 in the browser? Ugh... (Score:3, Insightful)
Better yet, we don't have any existing code for this system yet. It won't run ActiveX, so there's no code loss there. And now we're going to have to put the equivalent of Bochs or Qemu now into every browser on mobile devices? If you thought no Flash on the iPhone was bad, now all mobile browsers have to have Bochs/Qemu so they can run these plugins.
LLVM would be better. Or since these mobile systems are predominantly ARM, and ARM is more or less the predominant architecture everywhere (outselling x86 CPUs mostly because ARM is highly embeddable), why not make x86 emulate the ARM? x86 systems run faster than the vast majority of ARM systems, and would tax the x86 CPU less than a 400MHz one in say, the iPhone.
And really - why? Do we really need another Java equivalent?
Re:B.S. Article (No it's not) (Score:3, Insightful)
No it's not impossible. What is impossible is to reject "exactly all dangerous code" but they don't claim to do that.
A simple implementation will simply reject all code. There will not be any way to get dangerous code past that implementation so I have just made what you said was impossible.
What Google does is that they try to verify that the program is not dangerous. And if they can verify(Create a proof) that the program is not dangerous then they run it. Else they reject it.
This will result in Google rejecting valid programs which are not dangerous, but if google runs a program it knows its safe to run.
To be really useful you develop the compiler and verify code together, so that the compiler only issue code that it knows the verifier can verify.
Java does something like this. The java compiler only output code that it know that the Jvm can verify as valid, but if you write your bytecode directly, you can write valid non dangerous code that
the classloader will reject, because it can't prove that it's not dangerous.
Re:2^13? (Score:3, Insightful)
The java examples you showed had quake running at 1/8th the number of pixels as the C example from google.
Re:Why not look at java? (Score:3, Insightful)
Sure, Java has a great security model and will not cause buffer overflows. But you have to write it in (duh) Java.
The fun part about NaCL is that it can eat existing (C, C++, pick-your-own compiled language) code with only minor modifications to the compile chain, as long as that code does not make weird system calls. Just make sure that the compiler does not echo any of the 'forbidden' instructions, aligns jumps to 32-bit boundaries, and uses the prescribed instruction sequences for jumps and system calls. And they provide modified versions of GCC that do just that. The paper also says that, in their experience, modification of most programs they tried was, at most, a problem of "a few hours".
If I had to port an existing app to run as a sort of browser plugin, guess what sounds better: a full rewrite in Java, or a few changes to the Makefile. Because *that* is the selling point of NaCL.
Re:x86 in the browser? Ugh... (Score:2, Insightful)
I was thinking the same thing. The least they could do is use a nice neutral intermediate representation like LLVM bc and JIT compile it to whatever.
But what would they call this wonderful new concept? I suggest Java.
Re:gee - sounds exactly like... (Score:3, Insightful)
Fair enough. Sean Patrick Timmons, I'm sorry I'm not going to give you my SSN and DOB, though you might be able to find them anyway.
While I understand your issue with the hive mind the disagreements appears to be more rooted in ignorance than just opinions. Your supposition that closed source is more secure because the code can't be inspected is hilarious. In the same way that turning off a light and shutting the door makes a room secure.