Re: Heartbleed (was ... Re: My fellow (Debian) Linux users ...)
On 2014-04-17, ken <email@example.com> wrote:
> Steve brings up a very good point, one often overlooked in our zeal for
> getting so much FOSS for absolutely no cost. Since we're all given the
> source code, we're all in part responsible for it and for improving it.
I don't think the point is very good for the reasons outlined below (by
Robin Seggelmann, the OpenSSL developer who claims responsibility for
Heartbleed, says that both he and a reviewer missed the bug. He concludes that
more reviewers are needed to avoid a repetition of the incident -- that there
were not enough eyes in this case.
Another conclusion that might be drawn from Seggelmann's account is that
depending on developers to review their own work is not a good idea. Unless
considerable time passes between the writing of the code and the review, the
developers are probably too close to the code to be likely to observe the flaws
However, the weakness of Seggelmann's perspective is that the argument is
circular: if Heartbleed was undiscovered, then there must not have been enough
eyes on the code. The proof is in the discovery or the failure to discover,
which is not exactly a useful argument.
A more useful analysis has been offered by Theo de Raadt, the founder of
OpenBSD and OpenSSH...
(I'll quote most of de Raadt's usenet article--hope nobody minds).
So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed. Such
memory accesses will cause an immediate crash, or even a core dump,
then the bug can be analyed, and fixed forever.
Some other debugging toolkits get them too. To a large extent these
come with almost no performance cost.
But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
You can find the comment in their sources ...
/* On some platforms, malloc() performance is bad enough that you can't just
OH, because SOME platforms have slow performance, it means even if you
build protective technology into malloc() and free(), it will be
ineffective. On ALL PLATFORMS, because that option is the default,
and Ted's tests show you can't turn it off because they haven't tested
without it in ages.
So then a bug shows up which leaks the content of memory mishandled by
that layer. If the memoory had been properly returned via free, it
would likely have been handed to munmap, and triggered a daemon crash
instead of leaking your keys.
OpenSSL is not developed by a responsible team.