[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140519154302.GN507@brightrain.aerifal.cx>
Date: Mon, 19 May 2014 11:43:02 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: thoughts on reallocarray, explicit_bzero?
On Mon, May 19, 2014 at 08:31:31AM -0700, Isaac Dunham wrote:
> 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.
>
> 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.
>
> Should musl provide reallocarray()?
I don't think so; there's no precedent for it yet except OpenBSD.
LibreSSL should just add a fallback implementation (trivial to write
as a wrapper to realloc) for all non-OpenBSD systems that lack it.
I'm not fundamentally opposed to reallocarray, but I also don't think
it's useful to implement it unless there's a consensus from other
implementations on adding it.
> And what's the best way to ensure that memory gets zeroed out?
read() from /dev/zero? ;-)
Seriously, this is a tough one, because no matter what you try, a
smart enough compiler will work around it. There's the Annex K
memset_s, but Annex K is generally horrible. The OpenBSD approach of
"explicit_bzero" is also pretty bad since "bzero" is a deprecated
interface.
Note that there's not even a way to _implement_ this kind of
zero-filling without resorting to compiler extensions or asm. The
compiler is free (e.g. with LTO) to look inside the implementation and
determine that it does nothing.
Solar has one clever "solution" to this problem in the bcrypt code he
contributed to musl (see the source for the trick) but it's not an
explicit zeroing; rather it's a reuse of the buffer in a way that
would be very difficult for the compiler to optimize out.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
