Slashdot Log In
Google NativeClient Security Contest
Posted by
kdawson
on Mon Mar 02, 2009 08:10 PM
from the insert-favorite-salt-pun-here dept.
from the insert-favorite-salt-pun-here dept.
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."
Related Stories
[+]
Technology: Google Native Client Puts x86 On the Web 367 comments
t3rmin4t0r writes "Google has announced its Google native client, which enables x86 native code to be run securely inside a browser. With Java applets already dead and buried, this could mean the end of the new war between browsers and the various JavaScript engines (V8, Squirrelfish, Tracemonkey). The only question remains whether it can be secured (ala ActiveX) and whether the advantages carry over onto non-x86 platforms. The package is available for download from its Google code site. Hopefully, I can finally write my web apps in asm." Note: the Google code page description points out that this is not ready for production use: "We've released this project at an early, research stage to get feedback from the security and broader open-source communities." Reader eldavojohn links to a technical paper linked from that Google code page [PDF] titled "Native Client: A Sandbox for Portable, Untrusted x86 Native Code," and suggests this in-browser Quake demo, which requires the Native Code plug-in.
Firehose:Google NativeClient Security Contest by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Any project named NaCl (Score:5, Funny)
Simply has to be taken with a grain of salt!
Re:Any project named NaCl (Score:5, Funny)
Parent
Re:Any project named NaCl (Score:5, Funny)
Good one. It made me CaCl.
Parent
Re:Any project named NaCl (Score:5, Funny)
PbF!! Yeah right it did.
Will Slashdot receive the Nobel Prize in Chemistry for discovering the onomatopoeic bond?
Parent
Re:It made me cackle too (Score:4, Funny)
It's easy to get a reaction from a chemical nazi.
Parent
Re:Any project named NaCl (Score:4, Funny)
A name like that would poison support for their project.
Parent
x86 in the browser? Ugh... (Score:5, Insightful)
Parent
Re:Any project named NaCl (Score:5, Funny)
Q: Why did the bridge end up in police custody?
A: It was charged with a salt
Q: Why did the wire end up in jail?
A: It was connected with a battery
Q: How do you know the potassium did something wrong?
A: They were inside a cell
Parent
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.
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.
Parent
So what you're saying.. (Score:3, Funny)
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).
So what you're saying is..
Using just one half of NaCl could be poisonous, but when sprinkled atop the web as one all is well?
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
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:This is like the opening of a monster movie (Score:5, Funny)
where the scientist is saying he's covered all the bases, and nothing can go wrong.
If this is a monster movie, I'd hate to think what ActiveX was.
Parent
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:5, Funny)
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?
I contacted Google and their reply [google.ca] confirms your approximate amount.
Parent
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.
Parent
Re:2^13? (Score:4, Funny)
Looks like you already did.
/me ducks and runs
Parent
Sandbox, not preemptive code analysis (Score:4, Informative)
They're asking for people who are familiar in low-level x86 security fields to point out any issues from their experience that could compromise their sandbox.
Parent
Okay, some preemptive code analysis (Score:5, Informative)
Okay, they do preemptive code analysis inside the sandbox, too. Relevant portion of the PDF (section 2.2):
This then happens inside a sandbox where CPU segments are strictly enforced and any OS calls are trapped.
Parent
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.
Parent
Oops... (Score:5, Funny)
...guarantee hostile code simply cannot execute (PDF)
Hah! Was that a jab at Adobe?
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.
It's a good idea. But will they do it right? (Score:5, Informative)
I've read Google's paper, and I'm reasonably impressed. Basically, they've defined a little operating system, with 42 system calls, the same on all platforms, and defined a subset of 32-bit x86 machine code which can't modify itself and can't make calls to the regular OS. This requires using the seldom-used x86 segmentation hardware, which is quite clever and rarely used. But 64-bit mode has no segment machinery, so this approach doesn't translate to the current generation of 64-bit CPUs.
The biggest headache with Google's model is that they have to use a sort of interpreter to check all "ret" instructions, so someone can't clobber the stack and cause a branch to an arbitrary location. What's really needed is a CPU with a separate return point stack, accessed only by "call" and "ret" instructions, so return points are stored someplace that code can't clobber. (Machines have been built with such hardware, but there was never a compelling reason for it before.) Google has to emulate that in software. This adds a few percent of overhead.
Note that you can't use graphics hardware Google's OS. Conceptually, they could add a way to talk to OpenGL, which is reasonably secureable. But they haven't done that. They have a Quake port, but the main CPU is doing the rendering.
Interestingly, it would be quite possible to make a very minimal operating system which ran Google's little OS directly. You don't need the gigabytes of baggage of Windows or Linux.
It would also be possible to develop an x86 variant which enforced in hardware the rules of Google's restricted code model. That would be useful. Most of the things Google's model prohibits, you don't want to do anyway. (I know, somebody who thinks they're "l33t" will have some argument that they need to do some of the stuff Google prohibits. Just say no.)
The main question is whether the implementers will have the guts to say "no" to things that people really, really want to do, but are insecure. The Java people wimped out on this; Java applets could have been secure, but in practice they trust too much library, and library bugs can be exploited.
NSA Secure Linux has a similar problem. If you turn on mandatory security and don't put any exceptions in the rules, the security is quite good. But your users will whine and applications will have to be revised to conform to the rules.
Incidentally, the people who talk about "undecidability" and "Turing completeness" in this context have no clue. It's quite possible to define a system which is both useful and decidable. (Formally, any deterministic system with finite memory is decidable; eventually you either repeat a previous state or loop. For many systems, decidability may be "hard", but that's a separate issue. If termination checking is "hard" for a loop, just add a runaway loop counter that limits the number of iterations, and termination becomes decidable again. Realistically, if you have an algorithm complex enough that termination is tough to decide, you need something like that anyway. Formal methods for this sort of thing are used routinely in modern hardware design. Anyway, none of this applies to Google's approach, which merely restricts code to a specific well-formed subset which has certain well-behaved properties.)
Re:NaCl? (Score:5, Interesting)
Parent