[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is openssl actually safe now? (was: debian infrastructure ssh key logins disabled, passwords reset)



On Wed, May 14, 2008 10:21, BALLABIO GERARDO wrote:
> Peter Palfrader wrote:
>> Due to the weakness in our openssl's random number generator (see the
>> Debian Security Advisory #1571 from a few minutes ago[1]) that affects
>> among other things ssh keys we have disabled public key auth on all
>> project systems until further notice.
>
> Hi all,
> if I understand correctly, the problem was that openssl used some
> segment of uninitialized memory as a source of entropy, and the
> offending patch cleared it. Reverting the patch obviously restored the
> pristine behavior.
>
> However I wonder, is the pristine behavior correct? As far as I know, it
> is NOT justified at all to rely on the assumption that uninitialized
> memory contains random data. I read that many architectures reset it to
> some magic number, e.g., 0xdeadbeef. Is that correct?
>
> If so, and if that was the ONLY entropy source used in generating keys,
> then upstream openssl is (and has always been) just as broken as the
> patched Debian package. While if it was only used in addition to other
> sources, all this is probably a non-issue.

No no...in essence upstream OpenSSL did the following (after a quick
comparison of the Debian and upstream versions, please excuse any
oversimplifications):

a) allocate a buffer
b) add contents of unitialized buffer to entropy pool
c) get random data into buffer
d) add contents of initialized buffer to entropy pool

If the entropy pool is properly coded, there is no negative effect of
adding data which may or may not be truly random to the pool (i.e. you
cannot degrade the quality of the pool no matter what you add). Therefore
step b) might add some entropy or it might do nothing at all, depending on
how truly random the uninitialized data is, but it won't hurt.

The goal of the patch that was used in Debian's OpenSSL was to placate
valgrind by removing step b) as valgrind complained about the use of
uninitialized memory (here it was one of the few cases where it might be
legit to do so).

Unfortunately, step d) was *also* removed by that patch. And therein lies
the bug.

-- 
David Härdeman


Reply to: