The main technical point of Theo de Raadt's "exploit mitigation countermeasures" post is that even when the infrastructure it's running on is trying to add safety checks, OpenSSL will often neuter them. The specific example was the exploit mitigations in OpenBSD's malloc, which are neutered for OpenSSL because (for dubious stated reasons) it insists on wrapping the system malloc with its own caching variant. The same would apply, of course, to more straightforward measures like a malloc() which just cleared out the returned memory before turning it over to the app.
And this isn't the only thing about the OpenSSL codebase which seems likely to frustrate attempts at analysis. (Heck, the whole "forest of #ifdefs" thing has got to be at least a bit of a stumbling block.)
The main technical point of Theo de Raadt's "exploit mitigation countermeasures" post is that even when the infrastructure it's running on is trying to add safety checks, OpenSSL will often neuter them. The specific example was the exploit mitigations in OpenBSD's malloc, which are neutered for OpenSSL because (for dubious stated reasons) it insists on wrapping the system malloc with its own caching variant. The same would apply, of course, to more straightforward measures like a malloc() which just cleared out the returned memory before turning it over to the app.
And this isn't the only thing about the OpenSSL codebase which seems likely to frustrate attempts at analysis. (Heck, the whole "forest of #ifdefs" thing has got to be at least a bit of a stumbling block.)
Theo's email here: http://article.gmane.org/gmane.os.openbsd.misc/211963
HN discussion here: https://news.ycombinator.com/item?id=7558199