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."
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)
Re:Any project named NaCl (Score:5, Funny)
Good one. It made me CaCl.
It made me cackle too (Score:3, Funny)
It made me CaCl2.
(Calcium takes two anions.)
Re:It made me cackle too (Score:4, Funny)
It's easy to get a reaction from a chemical nazi.
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?
Re:Any project named NaCl (Score:4, Funny)
A name like that would poison support for their project.
x86 in the browser? Ugh... (Score:5, Insightful)
Re: (Score:2)
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.
Re: (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: (Score:3, Informative)
Amusing joke, but entirely dissimilar. It seems to me that if you want to prove that code doesn't do anything nasty, then a single-static-assignment IR could be very useful. JVM bytecode could never pull that trick. Also, LLVM imposes no runtime requirements whatsoever. None. It and Java are at opposite ends of that spectrum.
Re: (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 o
Re: (Score:2)
Well, you're close to hitting the nail on the head but not quite there.
You need to consider the difference between running on a non-x86 device, and running well on a non-x86 device. Let's say you write a Photoshop killer as a web app using NaCl. Do you really lose because NaCl is x86-specific? No. Even if there was some platform independent bytecode layer it would not help you. It'd just convert a webapp that didn't run at all on your iPhone to one that ran unusably slowly.
Phones and desktops/laptops are j
Re: (Score:2)
Are there any free, Free, caching, JIT recompilers which operate on x86 code?
Re: (Score:2)
Re: (Score:2)
Your "abstract solutions" all take orders of magnitude more memory than C, and still suffer garbage collection pauses.
Why isn't your web browser written using these "abstract solutions"? The answer is the same reason that having real machine code on the client is a win, for those who want to go to the trouble.
Re: (Score:2)
> Instead now we have Java, .NET and other "frameworks" which run one on top of the other and in the end it takes a dual core 2GHz CPU and 4GB of RAM to do the same things at a comparable speed that were possible to do using a 100MHz 486 and 32MB RAM.
That is simply not true. Java eats lots of RAM (and then some more), that is true, but it is not 20 times slower than native. JIT is our friend.
Re: (Score:2)
its not just the end-user resource usage and performance of these things. You also have to install them, I was thinking of installing a pretty subversion web-front end, I looked at sventon and it seemed quite good, no problem installing it... after I'd set up a JSP and Servlet container, plus JSP compiler and JRE. that assume I will get the correct version of all those things.
Its one thing to run the bloted apps, another to expect the system to be kept upto date with the bloated framework too.
Re: (Score:2)
on Linux, I'd do "yum install tomcat" and it should handle all the dependencies for me. Unfortunately my particular case I'm running Apache on Windows - its altogether a different story.
But.. that's not my point. I was trying to say how awkward in general it is to load a bunch of framework layers on top of the basic OS and then keep them updated and secure; not to mention that they tend to soak up proportionately more of your resources than simple native libraries.
Re: (Score:2)
while x86 in browser is not that good security-wise, using virtual machines, like Java, is slow. Just compare Azureus and uTorrent. And a ASM app would be even faster that uTorrent.
I was going to go off on a rant about how you clearly have no clue what you're talking about but then realised the fact you're clueless would prevent you from really understanding. It comes down to this though:
Az against uTorrent isn't a fair comparison, uTorrent has far less features than Az.
Java is as fast as native once compiled. To prove this try writing some basic sorting algorithms in C then Java and compare execution time. The overhead comes from the JIT compilation when you start the app.
Everything
Re: (Score:2)
So this contest will be a salt assault?
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
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
Re:NaCl? (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
You're a real salty dog, aren't you?
Re: (Score:2)
Re: (Score:2)
Who else was confused how Salt was going to help software security?
Not me. But I still can't see what this has to do with hashes.
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.
Re: (Score:2)
Are you saying NaCl is badly programmed, then?
Re: (Score:2)
short of any bugs in the sandbox itself
Which are exactly the sort of bugs the GP was talking about.
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.
Re: (Score:3, Insightful)
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.
Re: (Score:2)
My PC says the exact amount $8,191.997425203.
What? Why are you looking at me that way?
So what if my PC is a Pentium?
-
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:2^13? (Score:4, Funny)
Looks like you already did.
/me ducks and runs
Re: (Score:2)
No, he just has odd dance hobbies.
-
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.
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.
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: (Score:3, Informative)
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).
Java generally runs at ~30% slower than C. Unless NaCL can run faster than this then there's no point in it. The demo talk shows it running Quake at ~40 fps. Java quake runs at 200 fps [bytonic.de], on a much slower computer.
Re: (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: (Score:3, Insightful)
Re: (Score:2)
And then we will get the same problem as currently.
The attacker will not be able to escape the sandbox, but since all the things that matter to you will be running in the sandbox, that means you are still as fucked as before.
Unless of course you are a sysadmin and the only thing that matters to you is the system, not the user data.
Re: (Score:2)
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.
Forget that, you could solve the halting problem, prove P=NP and create true AI. Any effort towards this will be no more or less secure than the implementation of the virtual machine, simple as that.
Re: (Score:2)
It could be worse, Knuth only offers 80 hex dollars [wikipedia.org] for bugs in TeX. The actual check is worth far more in bragging rights alone!
Oops... (Score:5, Funny)
...guarantee hostile code simply cannot execute (PDF)
Hah! Was that a jab at Adobe?
Re: (Score:2)
I learned a LONG time ago to NEVER, EVER give slashdot a challenge you don't want fulfilled!
Re: (Score:3, Funny)
NEVER, EVER give slashdot a challenge you don't want fulfilled!
Chalenge:
1. RTFA!
2. ???
3. I win! (profit)
Anyone notify Google... (Score:2)
...their calendar is off by about a month. It's not April just yet. Either way, even if this is more than an elaborate practical joke, what can it do that Java Applets can't do? I don't know if we need yet another framework to run binaries on computers.
pre-compiled code? (Score:2)
tags: "google salt insane crap it security"
somehow that seems to sum up all the comments above me ...
anyway, formal software analysis is "hard"; its what compiler developers have been trying to do forever. Proving that code cannot do a specific subset of actions is not quite so hard, but some areas of security such as buffer overflows are inherently run-time only, and very hard to detect at the x86 level which doesn't quite have the concept of data structure, only a blob of memory assigned to a process.
IMO,
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: (Score:2)
No, no, no.
You can sandbox x86 code. It's been done multiple times in pre-VT virtual machines that use JIT to speed code execution. In short, VMs rewrite the code so 'safe' instructions are executed directly on CPU and 'unsafe' instructions are replaced with calls into virtualization layer.
NaCl uses the similar approach. But they don't bother with 'unsafe' instructions and just ban them.
Re: (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:
Re: (Score:2)
Java has a few problems NaCl doesn't, which is why NaCl has a chance at success and Java didn't:
Java was massive in every aspect. It took ages to download, install, and start. It nagged the user to update itself. This led to a very poor user experience. Nobody enjoyed accidentally visiting a web page that used a Java applet because your entire system would grind to a halt for 10 seconds whilst the JVM would heave its bloated carcass into RAM. I am told the very latest versions of Java fix this, but I care
Re: (Score:2)
Tons of useful and well debugged code is written in Java. If there's any general task, chances are very good there's a free Java library to do it. I doubt C/C++ comes anywhere close. I agree with some and disagree with some other of your statements, but I'm not gonna bite, why start a flamewar.
Re: (Score:2)
You could compile it with gcj, but you still have the problem of the giant runtime library. BTW get back to work dude, what if Gary sees you :-)
Re: (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 cal
20 minutes (Score:2)
Guarantee hostile code cannot execute (Score:2)
Re: (Score:2)
Re: (Score:2)
That hasn't been true since like 1980, when processors started coming out with MMUs. Learn: http://en.wikipedia.org/wiki/Memory_management_unit [wikipedia.org]
Re: (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: (Score:2)
Re: (Score:2)
Re: (Score:2)
That doesn't work either, because NaCl makes the code and data segments disjoint so that the code cannot modify itself or generate new code. Since the code never changes, it's sufficient to scan it once.
Re: (Score:2)
You should read the paper before saying things that are provably false.
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: (Score:2)
What annoys me is that by adding simple capabilities to the real operating system's syscalls, the operating system could do the same job as CaCl without having to compile programs specially. It's simple:
1. Open a FIFO (or shared memory, or other IPC method).
2. Fork.
3. Close all file descriptors except the FIFO.
4. Free up unused memory.
5. Drop all capabilities to system calls except for sys_read, sys_write, and sys_exit.
6. Read the code to execute from the FIFO.
7. Execute the code.
As long as the OS does its
Re: (Score:2)
That's too slow for many classes of apps though. For instance, good luck making Mirrors Edge run as a web app with that technique ...
Re: (Score:2)
I like this idea (I even suggested it myself at some point in the past). I don't think it has been implemented, but it should be a fairly simple change to the kernel. There is one issue with memory management though. The kernel already has the ability to restrict the amount of memory a process can use, but the process still need to make some system call to allocate it. This leaves a few options.
Won't work on 64-bit Windows? (Score:2)
I heard that much of the technique behind the design is to create x86 segments with a limit such that the sandboxed program can only access certain areas of memory within the process space. If this is true, the technique won't work at all in 64-bit Windows: Win64 doesn't have an API, documented or otherwise, to create segments in the LDT, unlike Win32. In fact, XP 64 and Vista 64 hardcode the LDT register to null. (Windows 7 64 has a limited LDT that appears to be related to SQL Server's "User-Mode Sched
Re: (Score:2)
Brad Chen touched on it a few times in the video [google.com]. Currently wouldn't support it and any future plans were still up in the air.
Re: (Score:2)
Fortunately, Win32 binaries (like NaCl) still run on 64-bit Windows.
Re: (Score:2)
64bit doesn't offer any compelling advantages to most end users, so the ability to run 32 bit code isn't going away anytime soon.
The Daily KDWTF (Score:2)
Today's kdawson WTF is proudly brought to you by the writers guild and Microsoft.
In an attempt to appeal the the nerds amongst us, kdawson today cited prize money amounts in Power notation.
For those of us who aren't binary nerds, and weren't able to pull the magic number straight the the subconscious regions of our brains, $2^13 = $8192 dollars.
I mean come on, does anyone still take this person seriously ?
Re: (Score:2)
Hate replying to myself, but does anyone else see the irony of this statement from the summary ?
that guarantee hostile code simply cannot execute (PDF)
Bearing in mind that PDFs are now also toxic, and very dangerous to download from anywhere.
Reuse of Existing C Code (Score:2)
It seems like the real benefit is not performance, but the ability to reuse existing C/C++ code bases on the web. A lot of people are looking at making web versions of well-established desktop apps (look at photoshop.com, for example). Currently you have to do this in Javascript/DHTML or Flash, which means throwing out all the code from your desktop app and writing something new from the ground up, which hopefully ends up looking more or less like the original system. It's a huge amount of work, and you end
Money? (Score:2)
Would you like a check for:
$$$$$$$$$$$$$8192
Re: (Score:3, Funny)
Which in turn sounds pretty similar to... Java!
Re: (Score:2)
well, java deals with the issue of security just by preventing any code to run. (check out spec for anonymous inner classes and this-> to just get worked up... ;))
Re: (Score:2)
Which, in some ways, is oddly like the Z-machine!
Re: (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....
Re: (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?
Re: (Score:2)
I know that English is a difficult language to master but nothing about my tense suggested the past. In fact since Google is actively pursuing experts to vet their shit I think will be is an accurate statement.
I'm not sure there ever has been an open source project like this one honestly but those security minded projects that ARE open source seem to do a pretty damn good job and get fixed rapidly when problems are discovered.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Ever heard of cross compiling/interpreting/VMs ?
Re: (Score:2)
Thank you. I didn't know and in my limited googleing (I'm in Iraq) I didn't see the things you were talking about. Why you're modded Troll and not imformative I don't know.
Maybe Moar == Troll
Re: (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.
Re: (Score:2)
What, are you saying it's impossible to prove a negative [wikipedia.org]?!
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 rej
Re: (Score:2)
A program that doesn't halt is not considered hostile; it's just annoying.