4 ms·
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 la
by arohner 17y ago
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?
- ax0n 17y agoI 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.
- ramchip 17y agoCould you back up that claim? lambdabot on #haskell runs arbitrary Haskell code very safely.
- ax0n 17y agoNo, 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.
- jpr 17y ago> 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.
- jrockway 17y agoI 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.
- ax0n 17y agoMost certainly. But further, it's possible to write unintentionally exploitable code in any language.
- jules 17y agoNo, you only need memory safety. Other than that you can make your language as crazy as you want.
- yacin 17y agoMemory safety _can_ be compromised in a cool, albeit unlikely, scenario: http://www.cs.princeton.edu/~sudhakar/papers/memerr.pdf http://www.cs.princeton.edu/~sudhakar/papers/memerr.pdf But for all practical purposes, you're right :)
- tbrownaw 17y ago1) 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
- jrockway 17y agoIn 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.
- tbrownaw 17y agoYeah, 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.
- jules 17y agoVery cool! Purity doesn't help defend against that either, unfortunately.
- tptacek 17y agoIt 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).
- tedunangst 17y agoIf 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?