Hacker News Reader

Comment by tetrep | Hacker News Reader

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

View on HN

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

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/

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.

Just build it with asan and you will get all the safety, memory usage and slowness of a memory safe language.

You'd need UBsan as well, and even that doesn't catch everything. Regarding memory usage/slowness: why not OCaml, D, or Rust?

Rust only recently hit 1.0, so it's pretty obvious why somebody would not have built their software using that.

Yes, my mistake.

Also, current benchmarks show Rust to be about ~3x slower than C, making it more comparable to Go or Java.

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.

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.

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.

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,

Reply on news.ycombinator.com