<= Archives =>
Another angle at the Heartbleed vulnerability
2014/04/09 11:45:23 CEST

Official description of Heartbleed.

Quoting de Raadt on misc@, April 08 2014:

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

And the details by Ted Unangst are worth reading.

Another interesting thing to monitor: how many operators will actually issue a password change request after fixing the vulnerability, like Ars did? How many silent fixes will there be?

This being said, everyone seems to focus on updating servers, but what about clients? They are vulnerable too.

Tags security heartbleed