> Date: Thu, 16 Nov 2000 19:12:23 +0100 (MET)
> Message-Id: <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Hmm... (discoveries about BIGNUM code)
> From: Richard Levitte - VMS Whacker <[EMAIL PROTECTED]>
> X-Waved: dead chicken, GNU Emacs 20.7.1, Mew version 1.95b43
>
> From: [EMAIL PROTECTED] (Peter Gutmann)
>
> pgut001> Currently the bignum code takes care to zeroise bignums after
> pgut001> they're no longer needed in all locations *except* when
> pgut001> realloc() is called, I see this as a hole in its security if
> pgut001> situations can occur where the zeroisation is bypassed.
>
> 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...
It is guaranteed on any POSIX-compliant UNIX system. or even a non-
compliant one that uses the BSD and/or AT&T allocator (and process-
creation) code. But *ONLY* when that memory is -first- allocated
from the O/S free pool.
Obvious corollary: any malloc()/alloc()/realloc() after the _first_
free() *may* get 'dirty' memory.
In those environments, memory allocated by malloc() and friends, even
if free()-d is =not= removed from the process address-space (execpt by
direct user manipulation of the 'break' [via 'brk()' or 'sbrk()' with a
negative increment] and will -not- be assigned to another process.
There are _lots_ of non-UNIX environments where one _cannot_ rely on
either of the above behaviors. Mostly of the 'dinosaur' vintage. (CDC's
SCOPE, KRONOS, NOS; IBM S/3, System34/36/38, DOS/360 [I think it's 'done
right' in DOS/VSE, but not sure]; DG's AOS, just to name a few.) And then
there's MS-DOS, and the abominations layered on top of it. Where you can
get 'dirty' memory, trivially.
NOTE: 'calloc()' is somewhat unique in the family, in that it _is_
documented as zeroing the memory block it returns. Convenient inside
ones own application -- of no 'added' benefit with regard to preventing
data from leaking _out_ of an application.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
