On Tue, Apr 8, 2014 at 12:40 PM, Theo de Raadt <dera...@cvs.openbsd.org>wrote:
> > On Tue, Apr 08, 2014 at 15:09, Mike Small wrote: > > > nobody <openbsd.as.a.desk...@gmail.com> 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. > > > Perhaps it's a great time to kickstart an OpenOpenSSL replacement, a la bgpd, ospfd, smtpd et al? Now, I don't have the skills or the guts, but I do have $5 on it. Anybody else?
