4 ms·

Read my post again cause you obviously didn't understand anything of what I wrote. You can have 2 components written in 100% safe language with no memory corru

Read my post again cause you obviously didn't understand anything of what I wrote. You can have 2 components written in 100% safe language with no memory corruption and no race conditions. You can have security critical race conditions that arise out of the interaction of same components. How is Rust or whatever solving this? It doesn't.

geofft 11y ago
Rust isn't just a safe language. It has other features. For instance, it's a much more strongly-typed language. You can use strong type systems to solve that exact problem. If you give me a more concrete example, besides "you can have race conditions," I can give you a more concrete way Rust fixes it, besides "you can use types."
- armitron 11y ago
  You still don't get it (this exchange is a great example of how hard it is for ordinary technically-minded people to shift into the proper mindset and begin to understand what the real issues are). The race conditions I refer to DO NOT EXIST in the static pieces of code written in Rust or whatever ivory tower language. They are EMERGENT pieces of DYNAMIC behavior that only manifest at RUNTIME due to subsystem interactions. And by subsystem I don't just mean pieces of code...
  - sanderjd 11y ago
    Can you give a concrete example of a recent major security issue caused by the sort of dynamically emergent interaction you're referring to? Anecdotally, the hair-on-fire security issues in fundamental components that keep coming up always seem to involve unsafe memory usage.
    - bpicolo 11y ago
      Buffer overflows seem to be a pretty recurring theme in these security issues, yep.
    - armitron 11y ago
      https://en.wikipedia.org/wiki/Row_hammer https://en.wikipedia.org/wiki/Row_hammer
      - geofft 11y ago
        Rowhammer is a very good point. Hrm. Rowhammer is basically mitigated if you don't let untrusted processes run CLFLUSH, right? That's sort of orthogonal to your choice of programming language (which might be your point, but then, I'm not sure I believe that Erlang or unikernels solves this either). It requires a world in which you've got something Native Client-like wrapping all userspace processes, which definitely seems like a good goal to work towards, and also seems easier to implement reliably in Rust than in C.
      - topspin 11y ago
        Row_hammer You're citing a hardware flaw as a reason not to pursue programming tools and techniques that produce fewer software defects? That's a false dichotomy; we don't forego researching cancer treatments just because some of the people that are saved will end up getting shot. Earlier you wrote "Security is all or nothing". That's another amazingly bad point of view. There is no "all." Nothing is absolutely secure. There is only raising the bar. Important things are provided more protection than less important things. That is the best that can ever be achieved. Since your premise relies on a fiction your conclusions about the value of Rust are meaningless.
  - geofft 11y ago
    I agree that they are emergent behaviors between multiple systems. I am claiming that these individual components can capture knowledge of other components via strong type systems, and thereby eliminate race conditions. Can you explain why this is untrue? I am trying to shift my thinking, but all I'm hearing is "No it can't." Can you explain why it can't?
smithkl42 11y ago
This reminds me of a post I once read arguing that type-safe languages weren't actually helpful, because they (generally) still let you write programs that could violate type safety. I thought that argument was silly, and I think yours is too. Yes, I'm quite confident that Rust isn't a panacea, anymore than functional programming will be, or object oriented programming has been, or type safety is. The point is that each of those techniques helps you to avoid certain classes of bugs. And so far as I can tell, Rust genuinely does have features that make writing certain kinds of bugs much less likely. Yes, Rust doesn't help you prevent every kind of bug. (Shocker!) But I don't get the point of insisting that decreasing an attacker's surface space isn't worthwhile.
- armitron 11y ago
  Security is all or nothing. There are no in-between states. If there's something to get from all my posts, is that we need to learn to operate with the assumption of compromise in mind, plan for failures and learn to rebuild, rapidly. Rust simply solves the wrong problems. For a language that certainly has the mindset, look at Erlang. Unikernels and Erlang will do more for actual security than a million monkeys cranking out perfectly safe Rust code. "Decreasing an attacker's surface" is pragmatically, bullshit. No competent attacker (and that doesn't include just nation states these days) will be deterred by a decreased attack surface.
  - smithkl42 11y ago
    Practically, I think it's wrong to say "Security is all or nothing", with no in-between states. Most attacks and/or security bugs are built on a combination of problems. Anytime you fix one of those problems, you make it less likely that someone will find a chain of problems that ultimately allows them through. If you take the example of the Heartbleed bug (a classic buffer overflow), it would still be possible to have written it in Rust, but it would have been more difficult, and hence less likely. That's a worthwhile trait for a language to have.
  - dcohenp 11y ago
    I'm sorry, but this line of argument is not even wrong as it relates to the entire modern infosec field, which is founded on the fact that there is no such thing as "100% security"; that is why concepts such as "threat models" and "defense in depth" exist. Also, proving a program "correct" (for some definition of correctness that presumably includes "secure") is undecidable, ergo there cannot be such a thing as a "100% secure language". No, not even Erlang, nor Haskell, nor anything which is remotely close to Turing-complete. So all we can do is, in fact, decrease the attack surface.
jerf 11y ago
"How is Rust or whatever solving this? It doesn't." Actually, yes, it does. The borrow checker composes. Two correct Rust components for race conditions and memory safety will indeed compose together correctly. That's a great deal of the point of the whole thing, after all. I don't think you've been keeping up with the state of the art in the last few years. Maybe less yelling and more listening is called for here.

geofft 11y ago

Rust isn't just a safe language. It has other features. For instance, it's a much more strongly-typed language. You can use strong type systems to solve that exact problem. If you give me a more concrete example, besides "you can have race conditions," I can give you a more concrete way Rust fixes it, besides "you can use types."

armitron 11y ago
You still don't get it (this exchange is a great example of how hard it is for ordinary technically-minded people to shift into the proper mindset and begin to understand what the real issues are). The race conditions I refer to DO NOT EXIST in the static pieces of code written in Rust or whatever ivory tower language. They are EMERGENT pieces of DYNAMIC behavior that only manifest at RUNTIME due to subsystem interactions. And by subsystem I don't just mean pieces of code...
- sanderjd 11y ago
  Can you give a concrete example of a recent major security issue caused by the sort of dynamically emergent interaction you're referring to? Anecdotally, the hair-on-fire security issues in fundamental components that keep coming up always seem to involve unsafe memory usage.
  - bpicolo 11y ago
    Buffer overflows seem to be a pretty recurring theme in these security issues, yep.
  - armitron 11y ago
    https://en.wikipedia.org/wiki/Row_hammer https://en.wikipedia.org/wiki/Row_hammer
    - geofft 11y ago
      Rowhammer is a very good point. Hrm. Rowhammer is basically mitigated if you don't let untrusted processes run CLFLUSH, right? That's sort of orthogonal to your choice of programming language (which might be your point, but then, I'm not sure I believe that Erlang or unikernels solves this either). It requires a world in which you've got something Native Client-like wrapping all userspace processes, which definitely seems like a good goal to work towards, and also seems easier to implement reliably in Rust than in C.
    - topspin 11y ago
      Row_hammer You're citing a hardware flaw as a reason not to pursue programming tools and techniques that produce fewer software defects? That's a false dichotomy; we don't forego researching cancer treatments just because some of the people that are saved will end up getting shot. Earlier you wrote "Security is all or nothing". That's another amazingly bad point of view. There is no "all." Nothing is absolutely secure. There is only raising the bar. Important things are provided more protection than less important things. That is the best that can ever be achieved. Since your premise relies on a fiction your conclusions about the value of Rust are meaningless.
- geofft 11y ago
  I agree that they are emergent behaviors between multiple systems. I am claiming that these individual components can capture knowledge of other components via strong type systems, and thereby eliminate race conditions. Can you explain why this is untrue? I am trying to shift my thinking, but all I'm hearing is "No it can't." Can you explain why it can't?

smithkl42 11y ago

This reminds me of a post I once read arguing that type-safe languages weren't actually helpful, because they (generally) still let you write programs that could violate type safety. I thought that argument was silly, and I think yours is too. Yes, I'm quite confident that Rust isn't a panacea, anymore than functional programming will be, or object oriented programming has been, or type safety is. The point is that each of those techniques helps you to avoid certain classes of bugs. And so far as I can tell, Rust genuinely does have features that make writing certain kinds of bugs much less likely. Yes, Rust doesn't help you prevent every kind of bug. (Shocker!) But I don't get the point of insisting that decreasing an attacker's surface space isn't worthwhile.

armitron 11y ago
Security is all or nothing. There are no in-between states. If there's something to get from all my posts, is that we need to learn to operate with the assumption of compromise in mind, plan for failures and learn to rebuild, rapidly. Rust simply solves the wrong problems. For a language that certainly has the mindset, look at Erlang. Unikernels and Erlang will do more for actual security than a million monkeys cranking out perfectly safe Rust code. "Decreasing an attacker's surface" is pragmatically, bullshit. No competent attacker (and that doesn't include just nation states these days) will be deterred by a decreased attack surface.
- smithkl42 11y ago
  Practically, I think it's wrong to say "Security is all or nothing", with no in-between states. Most attacks and/or security bugs are built on a combination of problems. Anytime you fix one of those problems, you make it less likely that someone will find a chain of problems that ultimately allows them through. If you take the example of the Heartbleed bug (a classic buffer overflow), it would still be possible to have written it in Rust, but it would have been more difficult, and hence less likely. That's a worthwhile trait for a language to have.
- dcohenp 11y ago
  I'm sorry, but this line of argument is not even wrong as it relates to the entire modern infosec field, which is founded on the fact that there is no such thing as "100% security"; that is why concepts such as "threat models" and "defense in depth" exist. Also, proving a program "correct" (for some definition of correctness that presumably includes "secure") is undecidable, ergo there cannot be such a thing as a "100% secure language". No, not even Erlang, nor Haskell, nor anything which is remotely close to Turing-complete. So all we can do is, in fact, decrease the attack surface.

jerf 11y ago

"How is Rust or whatever solving this? It doesn't." Actually, yes, it does. The borrow checker composes. Two correct Rust components for race conditions and memory safety will indeed compose together correctly. That's a great deal of the point of the whole thing, after all. I don't think you've been keeping up with the state of the art in the last few years. Maybe less yelling and more listening is called for here.