DNSSEC?
Jimmy Hess
mysidia at gmail.com
Sat Apr 12 17:10:01 UTC 2014
On Sat, Apr 12, 2014 at 9:17 AM, Michael Thomas <mike at mtcc.com> wrote:
> Malloc doesn't write over to-be allocated memory, calloc does. Using a
Zero'ing newly allocated memory is not the desired behavior. The
desired behavior is that a segmentation fault occurs, when an
application breaks the rules --- so the bug is detected, instead of
being hidden.
The system free() can be configured to write junk bytes to the entire
freed region, and malloc can be configured to align some allocations
to the end of a page (Which is a default on OpenBSD), and allocate
guard pages to cause a segmentation fault to occur if an attempt is
made to double free() or read past the end of the allocated buffer.
> wrapper is hardly unusual or controversial -- malloc can be expensive, and
> keeping lookaside list for, say, commonly used and fixed sized blocks is,
Use of the wrapper is both unusual and a bit controversial.
The openssl devs found some neat rope, decided to tie the noose, and
leave it permanently mounted around their neck, just praying some
script kiddie doesn't find the other end of the rope and tie it to
something.
> at least used to be, a big performance win.
A very small possible performance win, with an extreme potential
decrease in safety.
> Far from getting rid of evul wrappers, it seems to me that if they were
> smart with their wrappers they'd have wrapper routine for anything vaguely associated with wire output that zeros the allocated memory.
This doesn't help with reading beyond the allocated memory.
Of course........ if they correctly implement the same security
mitigations that are available from the malloc() library that the
system admin chose to install and link the application against,
then there would have been no security complaint.
> Mike
--
-JH
More information about the NANOG
mailing list