On Mon, Apr 21, 2014 at 12:34:12AM +0100, Kevin Chadwick wrote: > previously on this list people contributed: > > > On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote: > > > Hi, > > > > > > But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL > > > 1.0.1g. > > > > One of the problems with anything from OpenBSD is that they only > > care about OpenBSD, and if you want to use that fork you'll > > actually have to go and revert some of the things they're doing. > > > > Not true actually but of course their primary concern is naturally > OpenBSD. They takes POSIX seriously and atleast one patch has brought > it closer to POSIX standards. It is also clear to me that Theo wants > all to follow and benefit from best practice and bug hunting, the fact > that there is so much resistance is not his fault... is strlcpy still > rejected by glibc on the false premise of not solving truncation despite > better performance than strncpy and when it makes finding truncation > much easier! when used how they have been applying it to openssl. > > https://lwn.net/Articles/507319/
I'm not sure what you're trying to say here. But look at the example of the random number generator in my other e-mail. I've seen other cases were they do things like that. And I can perfectly understand why they do it, and then rely on that behaviour on OpenBSD, but it only works on OpenBSD. > > > It's now using native malloc/free instead of its own allocator > > > which allowed the Heartbleed bug to happen. > > > > This did not allow heartbleed to happen. It might have hidden > > CVE-2010-5298 more, but it was always there and is unrelated to > > heartbleed. > > > > It did because it would have been picked up likely weeks after the bug > was introduced due to OpenBSD and Gentoo hardened bug reports or static > analysis resulting in bug reports. As Theo says possibly before it was > actually released meaning all risk avoided "essentially for free". It seems you do not understand either vulnerability. - heartbleed: You send a packet and the other sides sends it back. Part of that packet contains a size which is not checked and that allows you to read more data than you send. If heartbleed wasn't been exploited there was no way to detect it. If it was being exploited, it can still go undetected assuming you limit the amount of data that you read. To be able to detect it with malloc() you probably need to give each malloc() it's own page and have a guard (before and) after it. - CVE-2010-5298: This has actually been reported 4 years ago already, long before heartbleed was introduced. This is a case where you call free() when you still have data, and you might have gotten that back in the next malloc(), or you might have gotton something else back. This is something that the native malloc() will probably have catched, but you see it with their implementation too. But this only happens when you turn on an option (not related to heartbleed) that not everybody uses and they most likely wouldn't have found this either. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140421085535.ga32...@roeckx.be
