Hacker News Reader

Comment by PythonicAlpha | Hacker News Reader

I did not check the contents of the article on correctness. It seems to me, that OPENSSL_Malloc is really only malloc by default -- but I lack the time to really check.

I wrote this sentence, because there is a big discussion ungoing, with some people blaming the self written allocator of OpenSSL. See the link, I gave. My point is, that even when it is so, having the standard allocator does not guarantee that you find this bug /in testing/ -- what is claimed in that article.

Correction: When you read the article of this topic exactly, the freelist implementation (allocator) is used for recvd data. That is what started the discussion.

View on HN

There is a big discussion going on that could be misleading.

To clarify, are we calling the freelist implementation, which the heartbeat code does not use, an allocator?

Update: I agree with the author that it is wrong to point the blame at the freelist implementation. If every C application that manages the reuse of commonly used data structures is doing wrong, then pretty much every modern server application will have to be re-written -- for instance Apache [1].

C is fast and portable and binds to just about any language which is why OPENSSL is in such wide use. Maybe it would be better to use more 'secure' languages like Go, but if OPENSSL was written in Go, how many applications would use it? I'd say almost none.

[1] https://apr.apache.org/docs/apr/1.5/group__apr__pools.html

A free list implementation is some kind of self made allocator.

I believe there is some confusion (at least I was confused until I looked at the code) that the library had universally replaced malloc with another allocator. While the library allows users to provide their own allocator, it is not done by default.

The code in question does not use the freelist implementation. It goes directly to OPENSSL_Malloc which is basically malloc.

What happened was the exploit allowed remote clients to read beyond the size of the buffer allocated by OPENSSL_Malloc. There just happened to be data from the freelist sitting next to it.

Even if the freelist implementation wasn't used, that wouldn't have prevented this exploit. There would just be something else sitting there in memory, but we can't predict what that would have been.

As much I understood the article (had also to look twice), the problem is not the OPENSSL_Malloc near the troublesome coding, but an other allocation for the received data. And that is (as much I understood) handled by the freelist. But the portions where of course allocated by normal mallocs.

Reply on news.ycombinator.com