Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google NativeClient Security Contest

kdawson posted more than 5 years ago | from the insert-favorite-salt-pun-here dept.

Security 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."

cancel ×

175 comments

Sorry! There are no comments related to the filter you selected.

Any project named NaCl (5, Funny)

iamacat (583406) | more than 5 years ago | (#27046483)

Simply has to be taken with a grain of salt!

Re:Any project named NaCl (4, Funny)

palegray.net (1195047) | more than 5 years ago | (#27046537)

Just wait till the KDE project gets their hands on this concept; we'll be seeing a new SourceForge project for KCl any day now.

Re:Any project named NaCl (4, Funny)

c0d3g33k (102699) | more than 5 years ago | (#27046681)

Good one. It made me CaCl.

Re:Any project named NaCl (0)

Anonymous Coward | more than 5 years ago | (#27046775)

clearly you're an evil overlord or a witch. They're the only ones who CaCl

It made me cackle too (3, Funny)

tepples (727027) | more than 5 years ago | (#27046977)

It made me CaCl2.

(Calcium takes two anions.)

Re:It made me cackle too (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27047365)

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:It made me cackle too (3, Funny)

SnowZero (92219) | more than 5 years ago | (#27048083)

It's easy to get a reaction from a chemical nazi.

Re:Any project named NaCl (4, Funny)

MarkRose (820682) | more than 5 years ago | (#27047603)

PbF!! Yeah right it did.

Will Slashdot receive the Nobel Prize in Chemistry for discovering the onomatopoeic bond?

Re:Any project named NaCl (3, Funny)

The Raven (30575) | more than 5 years ago | (#27046849)

A name like that would poison support for their project.

x86 in the browser? Ugh... (5, Insightful)

gravos (912628) | more than 5 years ago | (#27046539)

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.

Re:x86 in the browser? Ugh... (0, Redundant)

427_ci_505 (1009677) | more than 5 years ago | (#27046569)

Exactly. x86 in the browser? For the love of all that is good, why?

Preemptive answer to anyone justifying it: no.

Re:x86 in the browser? Ugh... (1)

pohl (872) | more than 5 years ago | (#27047009)

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:x86 in the browser? Ugh... (2, Insightful)

tlhIngan (30335) | more than 5 years ago | (#27048105)

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.

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:x86 in the browser? Ugh... (1)

debatem1 (1087307) | more than 5 years ago | (#27048471)

Personally, I look forward to the day when I can use *any* language as a web language- at native speed, no less. Sounds like a great reason to embed x86 to me.

Re:x86 in the browser? Ugh... (1)

Pentium100 (1240090) | more than 5 years ago | (#27048479)

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. 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.

Just compare system requirements for Office2007 on Vista and Office97 on Windows 95. Both Office versions do essentially the same thing.

Re:x86 in the browser? Ugh... (1)

CoughDropAddict (40792) | more than 5 years ago | (#27048503)

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:Any project named NaCl (1)

neomunk (913773) | more than 5 years ago | (#27046549)

So this contest will be a salt assault?

Re:Any project named NaCl (4, Funny)

gringer (252588) | more than 5 years ago | (#27046685)

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

Re:Any project named NaCl (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#27047269)

Q: What did the nigger kid get for Christmas?
A: Your TV

Re:Any project named NaCl (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#27047015)

if you want to make more money try out CodeGate http://beist.org/codegate2009.txt

Re:Any project named NaCl (0)

Anonymous Coward | more than 5 years ago | (#27048035)

How the hell did that get past the comment filters!?

NaCl? (1, Insightful)

Lumpy (12016) | more than 5 years ago | (#27046487)

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? (4, Interesting)

palegray.net (1195047) | more than 5 years ago | (#27046551)

Eh, it's an okay choice [wikipedia.org] for a project related to security.

Re:NaCl? (1)

techno-vampire (666512) | more than 5 years ago | (#27046865)

It's also a very reasonable choice from a programming [foldoc.org] POV.

Re:NaCl? (1)

spydink (256993) | more than 5 years ago | (#27047617)

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.

...and to come up with a saline solution.

Re:NaCl? (1)

techno-vampire (666512) | more than 5 years ago | (#27047763)

..and to come up with a saline solution.

You're a real salty dog, aren't you?

Re:NaCl? (1)

ThrowAwaySociety (1351793) | more than 5 years ago | (#27047391)

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.

gee - sounds exactly like... (-1, Flamebait)

Saint Stephen (19450) | more than 5 years ago | (#27046507)

.NET!

Re:gee - sounds exactly like... (2, Funny)

Nicopa (87617) | more than 5 years ago | (#27046643)

Which in turn sounds pretty similar to... Java!

Re:gee - sounds exactly like... (1)

KZigurs (638781) | more than 5 years ago | (#27046777)

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:gee - sounds exactly like... (1)

bcat24 (914105) | more than 5 years ago | (#27047495)

Which, in some ways, is oddly like the Z-machine!

Re:gee - sounds exactly like... (2, Insightful)

Lifyre (960576) | more than 5 years ago | (#27046665)

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:gee - sounds exactly like... (0)

Anonymous Coward | more than 5 years ago | (#27046723)

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.

Re:gee - sounds exactly like... (1)

Lifyre (960576) | more than 5 years ago | (#27046893)

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.

Re:gee - sounds exactly like... (1)

Ash-Fox (726320) | more than 5 years ago | (#27047271)

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.

A port of Microsoft's .net exists for BSD.

Re:gee - sounds exactly like... (1)

Lifyre (960576) | more than 5 years ago | (#27047295)

Is it for all of .net or just .net 1.1? I've never tried to use .NET on anything but my windows boxes...

Re:gee - sounds exactly like... (0)

Anonymous Coward | more than 5 years ago | (#27048225)

http://www.mono-project.com/Main_Page

Re:gee - sounds exactly like... (1)

obarthelemy (160321) | more than 5 years ago | (#27047125)

Ever heard of cross compiling/interpreting/VMs ?

Re:gee - sounds exactly like... (2, Interesting)

ClosedSource (238333) | more than 5 years ago | (#27046851)

"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:gee - sounds exactly like... (1)

Lifyre (960576) | more than 5 years ago | (#27046935)

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:gee - sounds exactly like... (0)

Anonymous Coward | more than 5 years ago | (#27047265)

...nothing about my tense suggested the past.

Except this part:

Has .NET been vetted by experts...

:P

Re:gee - sounds exactly like... (1)

tedu_again (980692) | more than 5 years ago | (#27047049)

www.mono-project.com

Re:gee - sounds exactly like... (-1, Troll)

ozphx (1061292) | more than 5 years ago | (#27047417)

Is .NET open source?

Yes. Google for Rotor moar.

Has .NET been vetted by experts in the way open source projects like this will be?

Yes. By paid experts, a year of running as "Terrarium" and also being vetted by black-hats as its been a default-enabled part of IE for a few years now.

Is .NET likely to ever be cross platform?

Yes. Google for Mono. Most shit I've written works under Mono.

Is .NET for running x86 code?

Google for JIT.

In fact, just google moar.

Re:gee - sounds exactly like... (0)

Anonymous Coward | more than 5 years ago | (#27047599)

Troll = Disagree?

Re:gee - sounds exactly like... (0)

Anonymous Coward | more than 5 years ago | (#27047823)

Easier to mod troll than google? Here - I did it for you:

The Shared Source Common Language Infrastructure (SSCLI), previously codenamed Rotor, is Microsoft's shared source implementation of the CLI, the core of .NET.

The Shared Source CLI was pre-configured to run on Windows, FreeBSD (version 4.7 or newer), and Mac OS X 10.2. It is designed such that the only thing that needs to be customized to port the Shared Source CLI to a different platform should be a thin Platform Abstraction Layer (PAL).

The current version of SSCLI is 2.0, which contains most of the classes and features of version 2.0 of the .NET Framework.

Re:gee - sounds exactly like... (0)

Anonymous Coward | more than 5 years ago | (#27047829)

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.

The code logic is amazing (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#27046553)

At runtime, it queries the code asking "Are you hostile?" If the answer is yes, it stops it cold, and if the answer is no, it runs. Truly an amazing achievement by Google here.

dangerous code impossible? (5, Insightful)

thermian (1267986) | more than 5 years ago | (#27046581)

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? (4, Insightful)

Cyberax (705495) | more than 5 years ago | (#27046647)

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:dangerous code impossible? (0)

Anonymous Coward | more than 5 years ago | (#27048609)

You don't get it. Bad programming produces bugs. You can't fix that with any tools. Arbitrary code execution is just one of the infinitely many bugs that could creep in just about any bad code.

Re:dangerous code impossible? (0)

Anonymous Coward | more than 5 years ago | (#27047387)

Why bother with x86?

I just dont get why nobody remembers the Juice oberon plugin.

Michael Franz has been working about safe jit-ing (in java as good as it gets, but much better in oberon) since before netscape became mozilla

Its just sad all the waste by curent fads, used in ways that werent part of the initial design goals (java, xhtml) mindless imitation ( .net ) or to please the lazy and ignorant crow.

Talk about moral crisis... any good enginer should see the knowledge frauds under current it trends

So what you're saying.. (2, Funny)

michaelhood (667393) | more than 5 years ago | (#27046609)

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. (5, Insightful)

Anonymous Coward | more than 5 years ago | (#27046637)

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 (3, Insightful)

Sloppy (14984) | more than 5 years ago | (#27046651)

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 (4, Funny)

cjfs (1253208) | more than 5 years ago | (#27046709)

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:This is like the opening of a monster movie (2, Insightful)

Sloppy (14984) | more than 5 years ago | (#27046885)

That's the original. This is Rob Zombie or Marcus Nispel remake.

Which do you prefer? (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#27046691)

Ninnle Linux or Niggerbuntu?

Re:Which do you prefer? (0)

Anonymous Coward | more than 5 years ago | (#27047657)

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!

2^13? (4, Insightful)

Moraelin (679338) | more than 5 years ago | (#27046693)

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? (4, Funny)

cjfs (1253208) | more than 5 years ago | (#27046737)

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:2^13? (3, Insightful)

Cyberax (705495) | more than 5 years ago | (#27046761)

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? (3, Funny)

grcumb (781340) | more than 5 years ago | (#27047099)

...you can can overflow...

Looks like you already did.

/me ducks and runs

Sandbox, not preemptive code analysis (3, Informative)

White Flame (1074973) | more than 5 years ago | (#27046815)

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 (4, Informative)

White Flame (1074973) | more than 5 years ago | (#27047407)

Okay, they do preemptive code analysis inside the sandbox, too. Relevant portion of the PDF (section 2.2):

The inner-sandbox uses static analysis to detect security defects in untrusted x86 code. Previously, such analysis has been challenging for arbitrary x86 code due to such practices as self-modifying code and overlapping instructions. In Native Client we disallow such practices through a set of alignment and structural rules that, when observed, insure that the native code module can be disassembled reliably, such that all reachable instructions are identified during disassembly. 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.

This then happens inside a sandbox where CPU segments are strictly enforced and any OS calls are trapped.

Re:2^13? (4, Interesting)

Tyger (126248) | more than 5 years ago | (#27046917)

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:2^13? (2, Informative)

cryptoluddite (658517) | more than 5 years ago | (#27047259)

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:2^13? (2, Insightful)

uid8472 (146099) | more than 5 years ago | (#27047261)

The idea is that programs are written in a heavily restricted subset of x86 that can be proven safe, where "safe" here basically boils down to not being able to make system calls or otherwise interact with the world without going through the sandbox library. The program might still be compromised by a third party if it's badly written, but then the attacker won't be able to escape the sandbox either.

Oops... (5, Funny)

TheUni (1007895) | more than 5 years ago | (#27046711)

...guarantee hostile code simply cannot execute (PDF)

Hah! Was that a jab at Adobe?

Re:Oops... (1)

supernova_hq (1014429) | more than 5 years ago | (#27048377)

Actually, it sounds more like a challenge to me.

I learned a LONG time ago to NEVER, EVER give slashdot a challenge you don't want fulfilled!

Anyone notify Google... (1)

guruevi (827432) | more than 5 years ago | (#27046797)

...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? (1)

andy_t_roo (912592) | more than 5 years ago | (#27046833)

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?

Re:pre-compiled code? (0)

Anonymous Coward | more than 5 years ago | (#27048611)

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.

It doesn't have to be so hard. I agree with you about the x86 instruction set. But there are plenty of languages out there that are amenable to this kind of analysis. Obviously, they cannot be fully amenable, but significant and absolute limits can be placed.

Haskell, for example, uses a Turing complete language for its algebraic data types. However, type inference is done via the Hindley-Milnor algorithm at compile. And only one (polymorphic) type has access to the outside world: IO a. If you eliminate or restrict that type, IO is impossible.

The Haskell analogue to a buffer overflow is probably a "too loose" function definition. Functions are typed. If we have a type A x = B | C x, we defined functions on that type with reference to their "type constructors". In this case, B or C. It would be problematic if a function on A x was defined for B and not C. For example, a complete function definition might look like:

identityOnAx :: A x -> A x
identityOnAx B = B
identityOnAx C x = C x

Obviously, if either of the equations were missing, the function's definition would be incomplete for the type. The function would not be "total" on the type. The function causes exceptional behavior in these circumstances. Simple best practices mitigate the problem, but the problem is also computationally tenable to determine at compile-time.

Errors causing corruption of memory in the underlying system are just not possible with a semantically correct Haskell compiler. The type system will just not allow it.

As much as I have gushed about Haskell, it is still a "research" language. It has found use in scientific, industrial, high assurance, and high-security fields because of the tangible benefits I have described. Microsoft hired Simon Peyton-Jones to continue to develop Haskell and further the functional programming field, and it's ideas are being incorporated into F#, a .NET language.

Haskell has significant limitations. It is by no means ready for the enterprise, and it probably never will be. It was designed as a convenient vehicle for conducting mathematics and computer science research. Its syntax and semantics are informed by the Howard-Curry Isomorphism theorem, which states that every theorem in a constructive logic is "equivalent" to some computer program. As such, it uses notation and constructs similar to those used in mathematics. An inheritance-like mechanism is implemented Its namespace system is not very refined. F# addresses these limitations, and tones the mathematical syntax down a bit.

It emphasizes "literate programming" orver enterprise practices. Indeed, using the Literate Haskell option produces source code which is fully compatible with LaTeX, without the need to comment text out. The net effect of all this is that one can sit down and write a proof, compile it, and have a running program.

Why not look at java? (4, Interesting)

ADRA (37398) | more than 5 years ago | (#27046863)

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:Why not look at java? (1)

Cyberax (705495) | more than 5 years ago | (#27046923)

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:Why not look at java? (3, Interesting)

Jahava (946858) | more than 5 years ago | (#27047915)

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:

  1. Full-scale protected/sandboxed application deployment, as per their Quake example
  2. Browser-based Web 2.0 content control, essentially replacing JavaScript with native code

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.

20 minutes (1)

BountyX (1227176) | more than 5 years ago | (#27047021)

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.

Guarantee hostile code cannot execute (1)

bluefoxlucid (723572) | more than 5 years ago | (#27047173)

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.

Re:Guarantee hostile code cannot execute (1)

Ash-Fox (726320) | more than 5 years ago | (#27047227)

I await your sample code doing this and sample code from a average 14 year old doing this too.

Re:Guarantee hostile code cannot execute (0)

Anonymous Coward | more than 5 years ago | (#27047235)

I can break that sandbox. A 14 year old could break that sandbox.

Congratulations, you just won $8,192. Wait, no you didn't.

Hint: Turing completeness has nothing to do with sandboxing.

Re:Guarantee hostile code cannot execute (1)

bluefoxlucid (723572) | more than 5 years ago | (#27047405)

This sandbox relies on preventing certain instructions to execute, i.e. the code is validated by a static checker. You can't continuously check the code without shitloads of overhead, which means this is (like anti-virus) a scan-and-allow process: program scans code, determines it's safe, and allows it to run. If the code does things that the program running it hadn't considered, things which allow it to get code that normally wouldn't pass into memory (hint: we have operating system level patches to prevent this, it's not doable at the application level), then it'll break the "sandbox."

Re:Guarantee hostile code cannot execute (1)

Wesley Felter (138342) | more than 5 years ago | (#27048509)

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:Guarantee hostile code cannot execute (1)

minsk (805035) | more than 5 years ago | (#27048519)

Fatal Error: Argument rejected due to straw man and false dichotomy. Please contact your argument distributor for more information.

Proving the set of operations executable by a general application is really hard. Which is why they greatly restrict the structure of the application.

Exclusively verifying code at runtime is expensive. Which is why they only use a few processor-provided features.

I have no intention of researching extensively enough to determine for myself whether the system really works. However, it is nowhere near as impossible or idiotic as you seem bent on portraying it.

Re:Guarantee hostile code cannot execute (1)

Craig Davison (37723) | more than 5 years ago | (#27047237)

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:Guarantee hostile code cannot execute (2, Insightful)

Craig Davison (37723) | more than 5 years ago | (#27047281)

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:Guarantee hostile code cannot execute (1)

bluefoxlucid (723572) | more than 5 years ago | (#27047377)

Hey, unless this is an OPERATING SYSTEM LEVEL PATCH to control the program? The MMU doesn't matter here. Considering they want to control WHAT INSTRUCTIONS EXECUTE, there's the obvious weakness that if you can get %eip pointed at an arbitrary binary stream, you bypass their entire security model. Win.

Re:Guarantee hostile code cannot execute (0)

Anonymous Coward | more than 5 years ago | (#27048177)

Considering they want to control WHAT INSTRUCTIONS EXECUTE, there's the obvious weakness that if you can get %eip pointed at an arbitrary binary stream, you bypass their entire security model. Win.

Uhm, read their paper? The whole idea is to statically prove that you cannot reach outside the sandbox. You can't point EIP outside the code segment. You can't point EIP in the middle of an instruction. You aren't running raw x86, you're running a subset of x86 which is statically analyzable.

Re:Guarantee hostile code cannot execute (0)

Anonymous Coward | more than 5 years ago | (#27047351)

If you're allowed to heavily restrict what instructions may be used, it can be made safe. It doesn't need an exact classification into "definitely safe" and "definitely unsafe": the analyzer can classify something as "possibly unsafe" and refuse it permission to run.

The only question is how restrictive the set of "definitely safe" programs is. The more complex the analyzer, the larger the class may be - but the greater chance there is of bugs in the analyzer. It is not very difficult to allow a "Turing-complete" safe set (within the bounds of real computers' finite address space). That's not a difficult project for even an undergraduate CS student.

The difficulty only comes when you want the safe set to include a very wide range of efficient programs that have access to a great many non-sandboxed resources.

B.S. Article (1)

Abuzar (732558) | more than 5 years ago | (#27047637)

Stopped reading here:

NaCl is designed to make dangerous code impossible

Ironically enough, that in itself is impossible. Obviously bullshit. You just wait, a 16-year old whiz kid is gonna prove it.

Re:B.S. Article (1)

VGPowerlord (621254) | more than 5 years ago | (#27047965)

What, are you saying it's impossible to prove a negative [wikipedia.org] ?!

Re:B.S. Article (No it's not) (2, Insightful)

TheSunborn (68004) | more than 5 years ago | (#27048581)

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.

Contest? (0)

Anonymous Coward | more than 5 years ago | (#27047729)

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.

Halting problem? (0)

Anonymous Coward | more than 5 years ago | (#27047873)

Complete dissasembly to detect hostile code? Isn't the set of all possible hostile actions similar to the set of all possible halting conditions?

Re:Halting problem? (1)

Wesley Felter (138342) | more than 5 years ago | (#27048513)

A program that doesn't halt is not considered hostile; it's just annoying.

It's a good idea. But will they do it right? (4, Informative)

Animats (122034) | more than 5 years ago | (#27047901)

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:It's a good idea. But will they do it right? (1)

hasdikarlsam (414514) | more than 5 years ago | (#27048537)

I could imagine some terribly clever things like, oh, the GHC compiler using code constructs that this forbids.

But I don't actually know whether it does. And if it does, it would be pretty easy to extend the instruction set to allow whatever it needs safely.

Re:It's a good idea. But will they do it right? (1)

DamnStupidElf (649844) | more than 5 years ago | (#27048865)

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 job, the new process is executing untrusted code perfectly safely. The only communication channel is through the open FIFO, which can be controlled completely by the parent process This requires the OS to handle things like the F00F bug properly, and doesn't account for timing attacks against cryptographic implementations, but I don't think CaCl can prevent timing attacks either. Most importantly, this is platform/architecture independent. It just requires the ability to permanently disable certain system calls for a process.

Another useless software from Google (1)

edivad (1186799) | more than 5 years ago | (#27048155)

Life is always nice at Google, relentlessly baking useless code 24h/day 7days/week.

Won't work on 64-bit Windows? (1)

Myria (562655) | more than 5 years ago | (#27048379)

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?

Re:Won't work on 64-bit Windows? (1)

cjfs (1253208) | more than 5 years ago | (#27048515)

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:Won't work on 64-bit Windows? (1)

Wesley Felter (138342) | more than 5 years ago | (#27048521)

Fortunately, Win32 binaries (like NaCl) still run on 64-bit Windows.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>