[ILUG] serious Debian/Ubuntu security hole found

[Padraig Kitterick]

Michael Watterson wrote:
> Justin Mason wrote:
>> Michael Watterson writes:
>>  
>>> paul at clubi.ie wrote:
>>>    
>>>> Not to be cranky, but the subject line was slightly deceptive - 
>>>> fixed. ;)
>>>>
>>>> Amazing tale though. There's just so much to marvel at here.. E.g. 
>>>> is anyone else bothered by the apparent strong dependence of the 
>>>> OpenSSL PRNG on uninitialised memory for entropy (since when does 
>>>> "uninitialised" == "random")?
>>>>
>>>> The blame game at:
>>>>
>>>>     http://www.links.org/?p=327
>>>>
>>>> is fascinating.
>>>>
>>>> regards,
>>>>       
>>> If you reboot without power off the memory may have original contents
>>> If  POST does some kind of memory test the memory may not be random
>>> Depending on design of memory, the initial state after power on may 
>>> not be random. Actually it may never be random if enough is known of 
>>> HW design.
>>>
>>> If it is cold and power is only off a short while, the memory is 
>>> preserved. This has been used to demonstrate reboot from USB stick 
>>> and finding passwords etc still in memory from last session.
>>> (all bets on security are always off if you have physical local access).
>>>
>>> It does seem indeed that two mistakes where made.
>>> 1) A stupid design by OpenSSL
>>> 2) A inept bug fix by Debian.
>>>
>>> The only 100% way I know to get a really random number  in a PC is a 
>>> 3.3V zener diode (white noise generator)  read by a 50 cent PIC A/D 
>>> converter then read via USB or I2C by the OS, or whatever other A/D 
>>> converter may be available. I use a zener for filter and frequency 
>>> response testing from 10Hz to 2GHz. A zener feeding a wideband 
>>> amplifier with a BNC socket. .
>>>     
>>
>> guys, it's not about the uninitialized memory really, you're missing the
>> point.  it's about the _other_ line of code the Debian guys commented --
>> where good sources of external entropy are added to the pRNG.   see
>> http://reddit.com/info/6j7a9/comments/c03zxko
>>   
> Yes we know that.
> And if there had been decent "comments" about what the two lines where 
> meant to do, one would have been removed earlier and the other left alone.
> 
> You can't sensibly review uncommented undocumented code, which is why 
> given a choice between "open source" that is undocumented && uncommented 
> and a well documented proprietary API, I'll use the API thanks. Life is 
> too short to figure out what other people's "write only" source code does.
> 
> 
> 

Commented or uncommented, applying a patch to security-crticial code 
just to stop errors being thrown up by an automated debug tool is a 
horrible idea. "Oh look, the error messages have stopped. It must be 
fixed". Or even worse: "Oh, my automated tool is saying there is a 
problem. Therefore, it must be a problem and I must fix it". Ugghh. 
Someone who thinks like that would not stop to read the comments, even 
if they were there.

If this had happened in a proprietary API and subsequently found, it 
would be fixed silently and the real dangers would not be known to the 
users.

Padraig.