5 ms·

I wonder if we'll ever get to the point where projects start advertising what methods they use to weed out memory management bugs (i.e. static analysis, fuzzing

by tetrep 11y ago

I wonder if we'll ever get to the point where projects start advertising what methods they use to weed out memory management bugs (i.e. static analysis, fuzzing, etc) because an adversary that can execute arbitrary code on my machine is far more intimidating than one that can eavesdrop (imo).

bobdole1971 11y ago
Speaking of that, I wonder why uTox & Tox weren't made in memory safe languages in the first place. There could be many possible reasons, so I won't bother speculating.
- irungentoo 11y ago
  Just build it with asan and you will get all the safety, memory usage and slowness of a memory safe language.
  - bobdole1971 11y ago
    You'd need UBsan as well, and even that doesn't catch everything. Regarding memory usage/slowness: why not OCaml, D, or Rust?
    - chc 11y ago
      Rust only recently hit 1.0, so it's pretty obvious why somebody would not have built their software using that.
      - bobdole1971 11y ago
        Yes, my mistake.
      - Jfreegman 11y ago
        Also, current benchmarks show Rust to be about ~3x slower than C, making it more comparable to Go or Java.
        chc 11y ago
        Interesting. Do you know of any good, recent benchmarks of Rust? I haven't seen a whole lot. The Benchmarks Game mostly appears to show Rust being closer than that in general, though the Rust benchmarks seem to be kind of crap.
        steveklabnik 11y ago
        A few months back, we were beating C on some benchmarks, though with the focus on semantics for 1.0, I'm sure there were some regressions.
- seagreen 11y ago
  Developer malpractice. Nothing security critical should be written in non-memory safe languages, unless you have no other option (like some embedded systems code). I'm not saying this to be mean. I've written lots of bad bugs myself. Humans are fallible-- that's why we have guards on saws, count pills twice in the pharmacy, and use modern languages when we're not in a sandbox.
irungentoo 11y ago
I made sure to make the packets in Tox as easy to parse as possible which greatly lowers the chances of fatal packet parsing bugs being present. As for the main tool I use to find bugs, it's asan (the clang address sanitizer) which is much more useful than static analysis for finding actual bugs. Of course the main thing I do to try to prevent bugs is reread the code again and again which is what catches pretty much everything. It's open source so anyone can run their favourite tool on it,
tux3 11y ago
I think that this is a very important point, and I'd like to quote Bruce Schneier in agreeing that "practical cryptography is rarely broken through the mathematics; other parts of systems are much easier to break" [0]. As a developer of a Tox client (qTox), I personally use a combination of static analysis (Coverity, CppCheck, Clang's scan-build) as well as dynamic analysis (notably the various *Sanitizers) to complement use of modern automatic memory management. But clearly as the many browser vulnerabilities found ever year show, bugs in large projects are a reality and there is no silver bullet, regardless of how sophisticated the current methods might be. I think that we should absolutely strive for fuzzing, analysis, testing and general security, not in the illusion that software will be perfect, but with the goal of preventing, catching, and fixing bugs before they become an actual in-the-wild threat. [0] https://www.schneier.com/essays/archives/1997/01/why_cryptography_is.html https://www.schneier.com/essays/archives/1997/01/why_cryptog...
- nickpsecurity 11y ago
  Consider using something such as SoftBound that transforms your code into one that defends itself against most memory attacks. There's a significant performance hit but immunity by design is better than hunting for every bug. Still try to code well, anyway, as the tools are usually limited to select platforms and you might want more portability. http://www.cis.upenn.edu/acg/softbound/ http://www.cis.upenn.edu/acg/softbound/
deleted 11y ago
[deleted]

by tetrep 11y ago

bobdole1971 11y ago

Speaking of that, I wonder why uTox & Tox weren't made in memory safe languages in the first place. There could be many possible reasons, so I won't bother speculating.

irungentoo 11y ago
Just build it with asan and you will get all the safety, memory usage and slowness of a memory safe language.
- bobdole1971 11y ago
  You'd need UBsan as well, and even that doesn't catch everything. Regarding memory usage/slowness: why not OCaml, D, or Rust?
  - chc 11y ago
    Rust only recently hit 1.0, so it's pretty obvious why somebody would not have built their software using that.
    - bobdole1971 11y ago
      Yes, my mistake.
    - Jfreegman 11y ago
      Also, current benchmarks show Rust to be about ~3x slower than C, making it more comparable to Go or Java.
      - chc 11y ago
        Interesting. Do you know of any good, recent benchmarks of Rust? I haven't seen a whole lot. The Benchmarks Game mostly appears to show Rust being closer than that in general, though the Rust benchmarks seem to be kind of crap.
      - steveklabnik 11y ago
        A few months back, we were beating C on some benchmarks, though with the focus on semantics for 1.0, I'm sure there were some regressions.
seagreen 11y ago
Developer malpractice. Nothing security critical should be written in non-memory safe languages, unless you have no other option (like some embedded systems code). I'm not saying this to be mean. I've written lots of bad bugs myself. Humans are fallible-- that's why we have guards on saws, count pills twice in the pharmacy, and use modern languages when we're not in a sandbox.

irungentoo 11y ago

I made sure to make the packets in Tox as easy to parse as possible which greatly lowers the chances of fatal packet parsing bugs being present. As for the main tool I use to find bugs, it's asan (the clang address sanitizer) which is much more useful than static analysis for finding actual bugs. Of course the main thing I do to try to prevent bugs is reread the code again and again which is what catches pretty much everything. It's open source so anyone can run their favourite tool on it,

tux3 11y ago

I think that this is a very important point, and I'd like to quote Bruce Schneier in agreeing that "practical cryptography is rarely broken through the mathematics; other parts of systems are much easier to break" [0]. As a developer of a Tox client (qTox), I personally use a combination of static analysis (Coverity, CppCheck, Clang's scan-build) as well as dynamic analysis (notably the various *Sanitizers) to complement use of modern automatic memory management. But clearly as the many browser vulnerabilities found ever year show, bugs in large projects are a reality and there is no silver bullet, regardless of how sophisticated the current methods might be. I think that we should absolutely strive for fuzzing, analysis, testing and general security, not in the illusion that software will be perfect, but with the goal of preventing, catching, and fixing bugs before they become an actual in-the-wild threat. [0] https://www.schneier.com/essays/archives/1997/01/why_cryptography_is.html https://www.schneier.com/essays/archives/1997/01/why_cryptog...

nickpsecurity 11y ago
Consider using something such as SoftBound that transforms your code into one that defends itself against most memory attacks. There's a significant performance hit but immunity by design is better than hunting for every bug. Still try to code well, anyway, as the tools are usually limited to select platforms and you might want more portability. http://www.cis.upenn.edu/acg/softbound/ http://www.cis.upenn.edu/acg/softbound/

deleted 11y ago

[deleted]