> On Tue, Apr 08, 2014 at 15:09, Mike Small wrote: > > nobody <[email protected]> writes: > > > >> "read overrun, so ASLR won't save you" > > > > What if malloc's "G" option were turned on? You know, assuming the > > subset of the worlds' programs you use is good enough to run with that. > > No. OpenSSL has exploit mitigation countermeasures to make sure it's > exploitable.
What Ted is saying may sound like a joke... 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.
