On 2014-04-17, ken <geb...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnlkv891.29q.cu...@einstein.electron.org
