| |||||||||||||
Cryptographic weakness on Debian systemsCryptographic weakness on Debian systemsPosted May 13, 2008 18:20 UTC (Tue) by tialaramex (subscriber, #21167)In reply to: Cryptographic weakness on Debian systems by noahm Parent article: Cryptographic weakness on Debian systems
It's interesting, looks like there's plenty of embarassment to go round. This function does not just take arbitrary "uninitialized memory" and feed it into the entropy pool. That would be stupid. It takes a parameter, which is supposed to be an array of entropy bytes to put into the pool. I haven't analysed the code enough to see whether the Valgrind reports are triggered by this function going off the end of the provided buffer, or by the buffer providers (elsewhere in OpenSSL code) not fully initialising their buffers, or even by a subtle false alarm (Valgrind is good but it's not perfect, not yet). In any case, with the patch removing this vital line of code, more or less none of the intended entropy ends up being used. Entropy from /dev/random, from hardware RNG sources, and so on, is discarded silently by Debian's patch AFAICT. Hence the list of millions of possible "bogus" keys which can be generated from the little remaining entropy. What's fascinating is that when Debian reported this terrible goof today some OpenSSL people said if they'd come forward with this patch two years ago the OpenSSL developers would have laughed at the obviously wrong fix... But it seems that Debian people did go to the OpenSSL developers two years ago, and they got told more or less that if it shuts up Valgrind then it's fine. Now in parallel to proposing this goofy patch, someone proposed to Debian a fix which simply writes zeroes to an uninitialised buffer elsewhere in OpenSSL. This patch seems to have been rejected by Debian for unclear reasons, but an equivalent change has been included in newer versions of OpenSSL and from there integrated back into Debian. It is probably one of several such fixes which should have taken place instead of this silly one line patch that disables the RNG more or less altogether.
(Log in to post comments)
Cryptographic weakness on Debian systems Posted May 13, 2008 18:42 UTC (Tue) by mbanck (subscriber, #9035) [Link] But it seems that Debian people did go to the OpenSSL developers two years ago, and they got told more or less that if it shuts up Valgrind then it's fine.That's interesting, do you have a link/citation for that? Michael
Cryptographic weakness on Debian systems Posted May 13, 2008 18:45 UTC (Tue) by jamessan (subscriber, #12612) [Link] http://marc.info/?t=114651088900003&r=1&w=2 is the thread on openssl-dev
Cryptographic weakness on Debian systems Posted May 13, 2008 18:45 UTC (Tue) by mbanck (subscriber, #9035) [Link] Probably this one, replying to the Debian openssl maintainer: http://marc.info/?l=openssl-dev&m=114652287210110&... Michael
Cryptographic weakness on Debian systems Posted May 13, 2008 18:51 UTC (Tue) by tialaramex (subscriber, #21167) [Link] Here's a smoking gun OpenSSL developer mailing list thread. Already linked above actually... http://marc.info/?t=114651088900003&r=1&w=2 I don't know if anyone in that conversation "represents" OpenSSL in some sense, but there was plenty of opportunity for anyone, even an interested bystander to interject "that is a terrible idea" and no-one did.
Cryptographic weakness on Debian systems Posted May 13, 2008 19:50 UTC (Tue) by nix (subscriber, #2304) [Link] Apparently that's a list for people developing apps *with* openssl, and the openssl devs don't all read it. (If so, well done openssl: not only is your code an uncommented stylistically awful dog's dinner, your mailing lists also have ridiculously misleading names. There's a reason I encourage GnuTLS use over OpenSSL wherever possible, and it's not the license...)
Cryptographic weakness on Debian systems Posted May 13, 2008 19:57 UTC (Tue) by jake (editor, #205) [Link] > Apparently that's a list for people developing apps *with* openssl, and the openssl devs don't all read it.That's what Ben Laurie said, but the web page for OpenSSL support says different: Discussions on development of the OpenSSL library. Not for application development questions! So it would seem like a reasonable place to ask questions of that nature. jake
Cryptographic weakness on Debian systems Posted May 13, 2008 20:16 UTC (Tue) by dark (subscriber, #8483) [Link]
The README distributed with openssl also says to submit patches to
openssl-dev. And the FAQ on openssl.org ("How can I contact the OpenSSL
developers?") says to look in the README.
Cryptographic weakness on Debian systems Posted May 14, 2008 0:42 UTC (Wed) by nix (subscriber, #2304) [Link] OK, I'll go and be quiet in the corner for not fact-checking before burbling. Apologies.
Cryptographic weakness on Debian systems Posted May 14, 2008 23:54 UTC (Wed) by cortana (subscriber, #24596) [Link] Well, don't feel so bad. The OpenSSL developers also didn't bother fact-checking either. ;)
Cryptographic weakness on Debian systems Posted May 15, 2008 4:20 UTC (Thu) by ajf (subscriber, #10844) [Link] If a member of the OpenSSL team got it wrong, you can hardly blame yourself for believing him.
Cryptographic weakness on Debian systems Posted May 13, 2008 18:42 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Let me offer a thought experiment that helps to show what's going on here, so far as I can
figure it out (and it's a bad sign that Debian's bug for this never gets anywhere near this
level of analysis)
Suppose I write a function int average(char *values, int count)
it takes 'count' bytes from the array pointed at by 'values' and is supposed to return an
arithmetic average, the mean value.
{
/* for simplicity let's not worry about overflow right now */
int total = 0;
for (int k = 0; k < count; ++k) {
total += values[k];
}
return total / count;
}
If you declare an array of 16 bytes, and pass it to me with the count of 16, then I will
return the average of those 16 bytes. Suppose you screw up, with an off-by-one error, and only
fill out 15 bytes, but still set the count parameter to 16, the size of your array. My
function will still work, it won't ever crash, and the result will be almost correct, since
whatever the value of the 16th byte, it will be dwarfed by the other 15 values in calculating
an average.
Now, when you run valgrind over the resulting program, it will report that my average()
function is faulty, it accesses an unintialised value.
Apparently at this point the Debian developers would say "Aha, stupid average function, we'll
soon fix that" and comment out the line total += values[k]; which is of course completely the
wrong fix.
Cryptographic weakness on Debian systems Posted May 13, 2008 20:02 UTC (Tue) by bcl (subscriber, #17631) [Link] That's a pretty good analogy. It isn't too obvious from just looking at the diff, but once you see the context you realize that they effectivly gutted ssleay_rand_bytes() and ssleay_rand_add(), and apparently the fix only fixes one of those? So it looks like there is still a problem.
Cryptographic weakness on Debian systems Posted May 13, 2008 21:15 UTC (Tue) by lambda (subscriber, #40735) [Link] No,
You can check the documentation in
|
|||||||||||||