noah pugsley | 9 Apr 03:05 2014

On Tue, Apr 8, 2014 at 12:40 PM, Theo de Raadt <deraadt <at>>wrote:

> > On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
> > > nobody < <at>> 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 ...
>  /* 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?