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

> 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

More information about the NANOG mailing list