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."
Re:NaCl? (Score:5, Interesting)
Re:gee - sounds exactly like... (Score:3, Interesting)
"Has .NET been vetted by experts in the way open source projects like this will be?"
What open source projects like this have been vetted by experts in the past? Who were they?
Why not look at java? (Score:5, Interesting)
You could beat them up for many things, but they have a working system of arbitrary code execution that generally doesn't expose your system to risk (unless you tell it to, and only when the code is signed, though self-certs are ok).
I'm sure there have been plenty of security advisories over the years, but the general philosophy is sane.
The problem with Java's implementation is that the code is run within Java, which itself has sand-box protection for all executed code. Unless Google is seeking an interpreted language client-side or Google only wants to allow execution of trusted signer code, I think their task is probably a fruitless one.
Re:2^13? (Score:5, Interesting)
The PDF was an interesting read, though I agree that the money they are dishing out is pretty paltry for all the free review they are trying to garner. Furthermore, I think they are taking platform neutrality in the wrong direction by locking the idea in to the x86 architecture.
But about how it would work, they are basically enforcing strict limits on how the code can be structured. The limits are designed to make the code easily analyzed. Anything that falls outside the strict requirements is rejected. It doesn't work for antivirus because they have to deal with any code that comes in without restriction.
As to why it doesn't work for OS... There is no reason the basic concept wouldn't, aside from the performance penalty and increased code size. (Though further compiler optimization could minimize or eliminate some of that).
However, if you want to go that route of making an OS do it, you might as well pick up a decent modern RISC architecture, because you're already breaking compatibility with any past program for any OS on the x86 CPU. Most of what they are doing is basically taking something that is standard on RISC and shoehorning it into the CISC architecture of the x86. Namely that instruction boundries can be reliably tested for jumps. They enforce that by requiring jumps only to 32 byte boundries, and then verifying each 32 byte block for correctness. Combined with disallowing self modifying code and eliminating the stack completely, all code that executes can be properly analyzed ahead of time.
The concept looks sound to me (Experience working low level with x86 architecture) but the security still relies on the implementation. Off the top of my head I can think of several ways to break the sandbox depending on how it is implemented. However the PDF is quite short on the details to evaluate the implementation. Namely, what exactly qualifies as an allowed x86 instruction, and for the syscalls that are checked, what the check is, not to mention the potential for bugs in the syscall handler for what would otherwise be valid calls, and even potentially the state of the OS or process when the protected code is executed.
Overall, I don't think this is the right direction for the web platform. Theoretically interpreted byte code should be more secure because it doesn't do anything that the interpreter doesn't explicitly allow (Javascript, Java, Flash, etc) and we see where that got us.
Re:Why not look at java? (Score:3, Interesting)
I am, myself, curious about this. Java seems to have a decent sandbox model already implemented through the JVM and Runtime APIs. Additionally, it is (or can be) platform- and architecture-independent, which seems more conducive towards Internet usage since it doesn't require an x86 instruction set.
While the Applet model is still viable, I think more mature alternatives (Flash, for example) obsolete it. Rather, I would wager Google is targeting two specific scenarios:
In the case of (1), a nice sandboxed application API for Java would be more than adequate. Most (or maybe even all) of the work is already done for this, including the signing and distribution of the application code.
(2), which seems really interesting, could still be easily (comparatively) accomplished via a low-level browser control API that is implemented in the various browsers either internally or via add-ons.
Not to knock Google's approach, for it does seem (from what I've read so far) well-thought out. What I am wondering, though, is what advantage they are seeking in choosing directly-native code over something like Java or .NET. If I recall, most modern Java metrics show it performing competitively with native code.
I understand that some of the appeal of NaCl is that they are attempting to provide verifiable proof that any code executed in their environment is secure. However, there looks like there would still be a root of trust in the NaCl implementation just as much as Java sandboxing relies on appropriate JVM implementation. I don't believe it is inherently more secure (although NaCl is likely less complex, so easier to evaluate).
As a research project, NaCl is very cool. However, to reach the goal of web content running at native performance, there are more mature technologies out there such as Java that are also more Internet-conducive. Google shouldn't re-invent the wheel; rather, they should pursue the existing powerful technologies, lay down some API and sandbox groundwork, and push for browser compliance.