Heartbleed .. and CRiSP

Excellent technical article on Heartbleed, and how it could
have been mitigated, and the state of software/security testing tools.

http://www.dwheeler.com/essays/heartbleed.html

A quick recourse on CRiSP. In the early days of CRiSP, it was unreliable -
bogus pointer derefs, use-after-free, and many things typical of C
code. I tried out Purify in the early days, along with other malloc()
detection tools, and they were helpful. Purify was an eye opener -
it detect many issues - on Windows and Linux, and helped me to get my
act together. I was really impressed with Purify.

I wrote my own Purify for the i386 - it was very slow (back when
a 200MHz Pentium Pro was king). It got close to being operationally useful,
but debugging it was painful - hitting a bogus instruction emulation
and figuring out where the problem was killed it. By then CPU speeds
were advancing, and although my implementation was 20x slower than
native speed, it was educational - I found some of the weaknesses of
Purify.

I built my own malloc checker - its the union of all malloc checkers
out there - can use mmap and guard pages for pre or post memory
reference checking, and its enabled via environment variables. I run with
it all the time - I get to find the bugs first. It can do
memory leak detection.

Purify was problematic due to the patents; eventually Valgrind came
along - a brilliant replacement for Purify and open source. It
bypassed the patent. (Most of Purify's patents have now expired, but the
world has moved on).

GCC and glib have improved with error detection.

The paper quoted above talks about clang's address-sanitizer. Its
not something you want in production code, but it is very desirable for
testing. I built CRiSP this morning with this turned on, and immediately
hit three bugs (1 fixed, 2 on my todo list). These are bugs that
have never shown up with any of the other tools (uninitialised stack reads),
so its excellent that the quality of tools is improving.

I have been working on my "ptrace" (strace replacement) to add crude
code-coverage reporting (based on all the functions in all the loaded
shared libs). This is getting close to working, so I will release
that when done. Code coverage is really just the start of software
testing - it tells you where you have gaps.

Its interesting that heartbleed happened - the focus by
everyone in the software community to do "better" has to be blessed.
We cannot afford another such bug - although undoutedbly they will happen,
but now, clever minds are targetting gcc, clang, glibc and many other
tools to make software development more enjoyable.

The best thing about all of this, and the tools, is that the technical
scenarios behind the tools and problematic code is getting serious review.
For me, this means higher quality tools and utilities I use daily.
For you (my crisp customers), it means the same.


Post created by CRiSP v11.0.31a-b6729