[ILUG] serious Debian/Ubuntu security hole found

[Michael Watterson]

Padraig Kitterick wrote:
> 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". 
Well, indeed there is a problem. But unless you wrote the code or 
working with the team you are unlikely to understand the problem. If I 
encounter this on distributed, released source, my 1st thought is that 
other people are using it so my tool chain must be configured wrong. I'd 
not want to change it.
> Ugghh. Someone who thinks like that would not stop to read the 
> comments, even if they were there.
Sadly many programmers think: successful compile == success.  Certainly 
not true with with C or C++. Slightly more true with C#, Java, Ada, 
Oberon and Modula-2
>
> 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.
Ah .. now that's a horse of a different colour.
>
> Padraig.
>
>
>
>


-- 
Mike