Re: thoughts on reallocarray, explicit_bzero?

[Szabolcs Nagy <nsz@port70.net>]

* Isaac Dunham <ibid.ag@gmail.com> [2014-05-19 08:31:31 -0700]:
> Having read up on the LibreSSL fork of OpenSSL and also recently
> backported a nuber of libXfont CVE fixes for integer overflows,
> I've seen the risk posed by malloc(n*sizeof(x)) and realloc(ptr,
> n*sizeof(x)).
> calloc(n, sizeof(x)) can be used in place of malloc(n * sizeof(x)), 
> but there's no standard function that does overflow checking for 
> realloc(). OpenBSD has provided the extension reallocarray(), which 
> provides for bounds checking like calloc() does.

i'd use a saturated multiplication, because malloc/realloc
are not the only places where overflowing size calculations
may cause problems and in such cases (size_t)-1 is just as
good as a failure and it can be added to your code without
portability issues

static size_t sizemul(size_t a, size_t b)
{
	return b>1 && a>1 && a>-1/b ? -1 : a*b;
}

> Additionally, there are times when a compiler will optimize away calls
> to bzero() on areas that are not used before free(); this can result in
> passwords getting left in memory. OpenBSD uses a wrapper function called
> explicit_bzero() to keep this from happening, thugh it seems to be possible
> to use some ugliness with volatile to stop it.

i don't see how the openbsd explicit_bzero stops the
compiler to do optimizations..

(i guess they rely on that their gcc does not do lto
or that libc is dynamic linked and the compiler has no
'explicit_bzero' builtin, neither of which is a great
solution..)

the usual approach to this is volatile function pointer:

static void *(*volatile force_memset)(void,int,size_t) = memset;

in general in c one cannot be sure that the secret bits
are not leaked somewhere since the languge spec cannot
give such guarantees

that said either the volatile funcptr or actually reusing
the memory such that it cannot be optimized away works in
practice

> Should musl provide reallocarray()? 
> And what's the best way to ensure that memory gets zeroed out? 
> 
> Thanks,
> Isaac Dunham