[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Heartbleed (was ... Re: My fellow (Debian) Linux users ...)



On 2014-04-17, ken <gebser@mousecar.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
others).

http://www.datamation.com/open-source/does-heartbleed-disprove-open-source-is-safer-1.html

 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
 in it.

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

http://article.gmane.org/gmane.os.openbsd.misc/211963

(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
 protective malloc.

 You can find the comment in their sources ...

 #ifndef OPENSSL_NO_BUF_FREELISTS
 /* 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.


Reply to: