Hacker News Reader

Comment by arohner | Hacker News Reader

IANA security expert, but stuff like this makes me believe it is never possible to secure native code. If you want a secure system, build a VM using a strict language like Haskell.

Is that a fair statement?

View on HN

It would be fair to sum up much of security and vulnerability research over the last 15 years as "trying to answer whether it's possible to secure a runtime when an attacker has limited but unanticipated access to raw memory". The weight of the evidence says "no", but secure runtimes are in their infancy (look at Google NaCL for a recent example).

I am a security professional, but not a developer. You're half correct. Your suggestion of a VM with Haskell would result in a system that could still be made to fail. The methodologies would just work differently.

Could you back up that claim? lambdabot on #haskell runs arbitrary Haskell code very safely.

No, because I know absolutely nothing about Haskell. I do know that if there was a silver-bullet language that was 100% "secure", everyone would be using it.

This attack is x86 machine-code-native, so Haskell in a VM is not vulnerable to the exact same problems, but to assume it's completely invulnerable is myopic.

> I do know that if there was a silver-bullet language that was 100% "secure", everyone would be using it.

This is completely false. Almost nobody in the software industry cares about safety. This can be proven trivially just by comparing how much more popular C and C++ are compared to memory-safe languages.

I think he means fail as in allowing you to write a function like:

  deleteAllFiles user = if user == Root
                           then throwError "access denied"
                           else unsafeDeleteAllFiles

Even if memory access is safe, you can still type in the wrong algorithm.

Most certainly. But further, it's possible to write unintentionally exploitable code in any language.

If you want a secure system, you'll have to answer how is the secure Haskell VM different than the "secure" Java VM, or Python VM, or Flash VM?

No, you only need memory safety. Other than that you can make your language as crazy as you want.

Memory safety _can_ be compromised in a cool, albeit unlikely, scenario: http://www.cs.princeton.edu/~sudhakar/papers/memerr.pdf

But for all practical purposes, you're right :)

1) wow, that is seriously awesome

2) hey, maybe we can get the music and film industry associations to mandate ECC as part of the license requirements for their next big DRM scheme

In case you were hoping #2 would lower the price of ECC memory, it won't. ECC memory is the same hardware as regular memory, you just have more of it; 4GB of ECC memory is just 7GB of regular memory with a different sticker on it. Since most people decide how much memory to get based on the price ("I'm willing to spend $100 on memory"), demand would remain unchanged.

Yeah, I know the price wouldn't change much. The real benefit I see is that Intel would have to stop disabling the ECC support on their desktop chips, and I'd have more choices available next time I'm up for a new computer.

Very cool! Purity doesn't help defend against that either, unfortunately.

Reply on news.ycombinator.com