Hey there,
On Thu, 16 Nov 2000, Richard Levitte - VMS Whacker wrote:
> I was wrong, it doesn't a realloc(), it does a malloc followed later
> on by a free(). However, I found no place where the expansion zeroes
> the previous memory, not even before I made my changes in there.
>
> I will take your words to heart and do the needed change. I agree
> with you that it's a concern, and for those wondering, the explanation
> that Peter doesn't provide is that free'd memory goes back to the
> system and may be given to other programs that allocate memory,
> without the memory getting touched, thereby giving the contents (for
> example a key) to some other random program.
>
> I know, many systems zeroes allocated memory for you (uhm, at least
> VMS usually does), but is that something anyone can guarantee? I
> definitely can't...
Hmm .. I'm not sure which way I feel about this. My instinct is to not go
plonking lots of memsets throughout the code if at all possible - as you
say systems such as VMS may already provide this - and others (embedded
devices, dedicated applicances, etc) may simply not need this addressed in
their threat model and would rather minimise memory activity, particularly
if avoiding the memsets results in less pages of memory getting dragged in
and out.
Might I propose another thought? We implement a sanitising heap around
malloc/realloc/free and allow it to be substituted in (or even substituted
*out* if we want it by default?) by calling a new
CRYPTO_set_safe_mem_functions(void) type of function?
It seems more orthogonal to me, espcially as we have this ability to swap
in and out malloc/realloc/free replacements. It also makes good design
sense to not muddy the details inside OpenSSL when it could be handled
cleanly once and for all in its own piece of libcrypto. I'm sure Peter
would also like the fact this could allow you to very simply alter the
sanitisation process (eg. sanitising with random bytes rather than '0', or
running multiple passes across the memory to leave no derivatives). If we
go for the memseting approach down in the bowels of all the other code
(X509, BIGNUM, SSL, RSA, DSA, DH, RAND, etc etc etc), we're more likely to
miss cases, slow down code for *everyone* (irrespective of the
appropriateness), and we still don't provide a solution for people who
need to sanitise memory *differently*.
Thoughts?
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
