Slashdot Mirror
Google NativeClient Security Contest
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."
Simply has to be taken with a grain of salt!
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
Do not look at laser with remaining good eye.
I'm sorry, I just don't buy this whole thing. x86 in the browser? Ugh... Because all that we need is to further promote an archaic instruction set that won't die because of all the pre-existing code compiled for it. An instruction set that was finally starting to loosen its grip as the industry worked toward more abstract solutions.
This game will waste your life. Don't clicky!
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.
A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
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?
Beware of bugs in the above code; I have only proved it correct, not tried it.
- Knuth
Which in turn sounds pretty similar to... Java!
where the scientist is saying he's covered all the bases, and nothing can go wrong.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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....
I'll meet you at the intersection of "Should be" and "Reality"
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.
A polar bear is a cartesian bear after a coordinate transform.
...guarantee hostile code simply cannot execute (PDF)
Hah! Was that a jab at Adobe?
Is .NET likely to ever be cross platform?
Is .NET for running x86 code?
How do you propose to fix the contradiction between those two?
It can't be cross-platform and platform native.
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... ;))
...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.
Custom electronics and digital signage for your business: www.evcircuits.com
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.
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, given that most new computers have multiple cpu's on-the-fly compilation to the most computer optimised binary is probably the best option - run interpreted for the first 10 seconds while some generic bytecode is compiled to PPC,SPARC,or perhaps even x86 instruction sets. (This assumes that there is a significant benefit by improving computability, and that compiling for a specific flavour of x86 is enough of a speed boost that it is worth while).
Given that "With reliable disassembly as a tool, our validator can then insure that the executable includes only the subset of legal instructions, disallowing unsafe machine instructions.", why not just start from the byte code and do forward compile as needed, rather than the reverse one?
"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?
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.
Bye!
Ok fair enough. I should have asked if you could run .NET outside of windows. There is a fair shot that this will work in environments like Linux of Mac.
I'll meet you at the intersection of "Should be" and "Reality"
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.
I'll meet you at the intersection of "Should be" and "Reality"
It made me CaCl2.
(Calcium takes two anions.)
I spent about 20 minutes trying to defend Google and how cool it would be to have a browser like extension where a user can specify a sandbox and configure it (like sandboxie), then have developers exploit it to execute in that environment. Alas, it is novel at best.
Trying to install linux on my microwave, but keep getting a kernel panic...
www.mono-project.com
Ever heard of cross compiling/interpreting/VMs ?
The Cloud - because you don't care if your apps and data are up in the air.
We're talking about something that's got to be turring-complete in the end, gets evaluated before hand, turned loose to run directly on the processor. I can break that sandbox. A 14 year old could break that sandbox. There is no magically unsafe instruction.
Support my political activism on Patreon.
...nothing about my tense suggested the past.
Except this part:
Has .NET been vetted by experts...
:P
A port of Microsoft's .net exists for BSD.
Change is certain; progress is not obligatory.
Is it for all of .net or just .net 1.1? I've never tried to use .NET on anything but my windows boxes...
I'll meet you at the intersection of "Should be" and "Reality"
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.
Which, in some ways, is oddly like the Z-machine!
Troll = Disagree?
Stopped reading here:
Ironically enough, that in itself is impossible. Obviously bullshit. You just wait, a 16-year old whiz kid is gonna prove it.
It's a tough choice. On one hand, I am what I am because of how apes behave. On the other handle, ninnle ninnle ninnle ninnle ninnle ninnle ninnle ninnle BATMAN!
Contests like this are total bullshit. They get thousands of free work hours for a couple grand.
A few people will make enough money to pay this months rent while Google is off making billions of dollars.
Don't be a sucker.
Easier to mod troll than google? Here - I did it for you:
Is .NET open source?
Is NaCl going to be infected with the GPL?
Has .NET been vetted by experts in the way open source projects like this will be?
Is NaCl going to be at all secure if just anyone can look at the source?
Is .NET for running x86 code?
Is NaCl able to run ARM code?
Now I'm no expert and could be way off base...
Correct.
Complete dissasembly to detect hostile code? Isn't the set of all possible hostile actions similar to the set of all possible halting conditions?
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.)
Life is always nice at Google, relentlessly baking useless code 24h/day 7days/week.
http://www.mono-project.com/Main_Page
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 Scheduler".)
Does anyone know whether I'm correct about Google's project?
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
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.
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 ?
> What open source projects like this have been vetted by experts in the past? Who were they?
The Linux kernel has been vetted several times. Not to mention there have been many people who tested their automated bug finders on random large open source products. Examples fail me at 3 AM, but I'm pretty sure there were some recent Slashdot stories about them.
Separately, the Open BSD kernel gets a full audit every time a new kind of bug is discovered. That's why they've had only one remote root exploit in the default install in years now.
Most shit I've written works under Mono.
At least you admit it.
If I am not mistaken Adobe has a similar project called Alchemy. They are compiling C code into swc.
http://labs.adobe.com/technologies/alchemy/
I guess if you want to run proper applications in your browser you need this.
So Google will have Native Client.
Adobe will have Alchemy.
Can't wait MS coming out with the same stuff.
That will be beautiful. A major mess up on all side.
Which in turn sounds pretty similar to... Java!
Actually the validation of NaCl code sounds a lot like validation of java bytecode. However NaCl is a subset of valid x86 code, which means it should be able to perform faster than java bytecode. If you are not running on an x86 architecture, you are probably going to get better performance from java bytecode. Java bytecode is a higher level than x86 code, since it is inherently tied to the java OO model (Not saying this is good or bad, just that it is different). A java bytecode JIT compiler can use the full x86 instruction set if it wants to, so in theory it could perform better than NaCl. But the JIT compilation and the difference between the OO model and the native code does give some performance overhead, compare this to the performance you lose by restricting code to the subset of x86 allowed by NaCl, and the outcome is unclear. (I guess NaCl is going to come out a winner, but maybe java JIT compilers will get close). I wonder if it would make sense to compiler java bytecode to NaCl code, and maybe even implement the JIT compiler in NaCl code.
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 up with two completely separate code bases to maintain.
If you could just recompile all your C code and dump it in the browser, it's a huge win. Of course you'll still need to write a browser-friendly UI (and I'm not sure how that works in NaCl currently), but all your back-end code (like the filters in Photoshop) could be reused.
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
I'll meet you at the intersection of "Should be" and "Reality"
The NaCl system does this.
Would you like a check for:
$$$$$$$$$$$$$8192
-- I was raised on the command line, bitch
Does this include the case where the machine code implements a byte code interpreter along with a bunch of byte code data? That makes analyzing the code a bit more complex.
J
> Is .NET open source?
Microsoft's implementation is not, of course, but Novell's is: http://mono-project.com/Main_Page
and the spec is standardized: http://www.dotnetexperts.com/ecma/
> Has .NET been vetted by experts in the way open source projects like this will be?
Depends if you consider people like Herb Sutter and Anders Hejlsberg experts.
> Is .NET likely to ever be cross platform?
http://mono-project.com/FAQ:_General#Mono_and_Microsoft
> Is .NET for running x86 code?
No, and thats a good thing.
> Now I'm no expert and could be way off base but there seem to be some pretty major differences here....
Too bad Sun is uninterested on having more desktop adoption of Java. Sun's incompetence / arrogance is the reason we have this and SilverLight.
I browsed the PDF, and it seems they have some trampoline code in the first 64KB of memory that has unsafe instructions that allow that code to do more dangerous things. The idea is that the untrusted code can only interface with the trampoline code, which checks that nothing funny is going on, then it interacts with the real OS.
I see a primary weakness is that they support threads. Start a thread, and have it try to interfere with another thread calling the trampoline code. Basically, mess about with the "stack" trying to get it to jump to a non-32-byte boundary. The trampoline code seems to be a very weak spot, and attacking it seems like the easiest area to go after. It's very difficult to make the trampoline code safe from attacks from other threads in the same address space (it actually may not be possible to make it bullet proof). Try to attack the trampoline to make failing security checks into passing ones--the idea is the trampoline code has to store data somewhere--just try to modify it.
I think they may have some weaknesses in mmap, mprotect, etc.--they need to check these calls very carefully. Try to remap the trampoline code to another address (which would then be vulnerable). Try to map in a library over the trampoline code. The PDF itself said they check open() carefully, but then not read()...this shows they are probably being too clever and not defensive enough.
Another area is create races--is it possible to provide one copy of the code to the checker, and another copy actually gets loaded into memory? This is surprisingly difficult to get right, but depends a great deal on how they load code (or, rather, how the code is presented to them in the first place, I guess by a browser).
Note that any check the trampoline code makes might be bypassable by a clever thread, which changes the data after the sandbox check is complete but before the OS call is made. OS calls which take in buffers probably don't "snapshot" the data to protect it being changed by threads, so there may be a large window in which threads can break the sandbox security (the security check passed, but then a thread changes the data to unsafe values before the OS acts on it).
And of course, try to break out of the sandbox by exposing OS-level bugs or just extreme events such as opening too many files, overflowing structures, to create a way out of the sandbox.
If you have time to try all of the above, enjoy your $512.
I'm baffled that after all the tireless work of browser implementors, virtual machine implementors (java etc.) over the years, somebody has come up with a brainwave that making a runtime platform tied directly to a specific to a processor architecture is a good idea. Sure we happen to be at a juncture in history when we have 3 major platforms (windows, mac, linux) all primarily using intel processors, but this still seems nutso nonetheless. The fact that the described scheme does not work on 64 bit processors seems to make it completely useless as surely 64bit is going to be come standard within a year or two.
Have it both ways.
You are what you are because of how BATMAN behaves!
or
Ninnle ninnle ninnle ninnle ninnle ninnle ninnle ninnle APESHIT!
While I know that the GPL has it's problems I've never heard it termed an infection before, though your opinion that it's like a virus should be surprising since by your logic Windows is secure because you can't look at the source.
Yes, it would be nice is NaCl could run ARM code and I know that running x86 code is not likely to end well. I'm open about my lack of expertise, yours is obviously suspect, and I at least had the balls to sign my inflammatory ignorant statements.
I'll meet you at the intersection of "Should be" and "Reality"
smexy it means I might be able to start running my work box as a linux box and get away from all the crazy shit they restrict on windows machines (no USB on windows boxen)
I'll meet you at the intersection of "Should be" and "Reality"
So there you have reason one: It's C and there's a lot of code in C that could be useful in a browser context. Think of multimedia codecs. Stop blaming the HTML5 committee for not including Ogg theora in their HTML5 standard. "Just" port Ogg to NaCl and it runs in our browser. Bingo! Think of games like Quake which are brought to your browser with ActiveX. With NaCl it would run under Linux and OS X too (on X86 ...).
And regarding LLVM: I see no reason why NaCl and LLVM could not profit from each other.
And if you are really cool: Port KDE to NaCl ;-)
-- "As a human being I claim the right to be widely inconsistent", John Peel
I don't understand why Ninnle keeps getting modded down.
As every security expert knows, you start a set of rules by forbidding everything, and then making the smallest possible exceptions to make it run. And nothing more.
This looks the other way around. So it is just as flawed as all those Internet-filters that we constantly bash here on Slashdot.
Oh well, call me backwards, but I went from web application development with JavaScript and PHP to classical software development in Haskell, with dynamic libraries an plug-ins.
I felt the whole web app space to be a major case of the "inner platform effect"
Any sufficiently advanced intelligence is indistinguishable from stupidity.
You said balls, hehe. How about using your full Real Life name to sign your inflammatory ignorant statements though? Anything other than that doesn't require balls.
The reason I don't use a username anymore is because I disagree with the karma system. I don't agree with the hive mind here at /. and eventually all of my posts end up starting at less than zero.
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.
I'll meet you at the intersection of "Should be" and "Reality"