Re: Thanks to Debian OpenSSL developers
On 080516 at 08:00, Yves-Alexis Perez wrote:
> On jeu, 2008-05-15 at 23:38 +0200, Steffen Schulz wrote:
> > or what its worth...I see 3.5 problems that accumulated into this
> > mess:
> >
> > - OpenSSL is complex and critical but the code is little documented.
> > Code pieces like the ones in question should have warning-labels
> > printed all over them and a distinguished place and interface.
> There was a #ifndef PURIFY just before the instruction commented by #if
> 0.
Exactly.
The comments in openssl(or mozilla/NSS, for that matter) are helpful
only to those who already understand what the code does. But even then
the programmer still doesn't know what the author *intended*.
actual code <-> authors intention <-> correct behaviour(iso/rfc/best pr.)
These are three different things and I tend to comment sensitive code
at two levels to link these.
> > - There are published algorithms for good PRNGs, no need to help
> > yourself with adding unintialized memory and praying the OS does a
> > good job already.
> You talk about the first instruction which doesn't add entropy in every
> case, but doesn't hurt (except the lintian warning).
> The problem was with the second one, which added the entropy pool the
> content of a now initialized buffer.
As I said, several problems accumulated. A clear description in high
and low level of the implementation of an approved PRNG could have
prevented $tool to complain about code quality and $hacker to fix the
wrong stuff.
Making the code more accessible also makes it easier to build up
expertise at 3rd parties, so you don't have to rely on the 2 core
devs to only approve code that doesn't mess up any unspoken rules.
> > - I don't know how much of an effort was made, to get the fix into
> > upstream, but it seems it wasn't enough. Not enough to get a
> > sufficient level of peer review. Instead it was decided to manage
> > yet another debian-specific patch.
> There wasn't any fix, that's why. The “#ifdef PURIFY” was there for a
> reason.
I mean, trying to take the (bad) patch into upstream would have
produced more peer review and most likely the error would have been
discovered. (Either that or debian wouldn't be the only affected
distro, win-win ;))
To me thats another aspect why security failed here. And its an aspect
that could be covered by policy in Debian so that it is less likely to
happen again. It's the only thing Debian can do by itself, it can't
influence openssl comment and development practise.
I'm not saying 'you should do this and that', I'm just trying to
discuss what measures could limit the rate such errors occur at.
/Steffen
--
Bildet Olsenbanden!
Reply to: