> So the focus on the self-written allocator seems to get a little biased in this discussion.
I feel like I'm missing something here. Where are the self written allocators? This article states that the OPENSSL_Malloc is simply malloc by default.
I feel like I'm missing something here. Where are the self written allocators? This article states that the OPENSSL_Malloc is simply malloc by default.
If OpenSSL had just written a malloc(3) implementation that sat in a separate shared-object--the way that, for example, jemalloc does--then switching it out would be a simple and obvious linker argument. Any developer who had used a project that relies on an alternate malloc (e.g. redis) would know that "test while linked against system malloc" is a crucial step.
Instead, you have to learn that there's a specific OpenSSL debugging flag that disables the "caching behavior" of the malloc wrapper, causing it to become a passthrough to regular malloc. None of the tests use this flag.
But where are they called from?
Update: To answer my own question the freelist is used in
ssl3_setup_read_buffer()
ssl3_release_read_buffer()
ssl3_setup_writer_buffer()
ssl3_release_write_buffer()
To be clear, this is NOT TRUE. The freelist is used for some allocations, but not in the patch in point. Here is the patch that addresses the bug: https://github.com/openssl/openssl/commit/731f431497f463f3a2...
It clearly uses OPENSSL_Malloc which is basically the equivalent of calling malloc.
https://github.com/openssl/openssl/commit/731f431497f463f3a2...
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.
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
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.