| |||||||||||||
Cryptographic weakness on Debian systemsCryptographic weakness on Debian systemsPosted May 13, 2008 15:09 UTC (Tue) by jwb (guest, #15467)In reply to: Cryptographic weakness on Debian systems by pharm Parent article: Cryptographic weakness on Debian systems
Is it just me, or did the "fix" only back out the change in one of two places? See the patch which caused the problem: http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/r... The offending change is in two places. Now see the "fix": http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/c... The patch is only half undone. Oversight?
(Log in to post comments)
Cryptographic weakness on Debian systems Posted May 13, 2008 15:17 UTC (Tue) by hmh (subscriber, #3838) [Link] I suggest studying the utility mentioned in the advisory that verifies whether a key is weak or not. That goes directly to the effect of whatever bug is in question (which is what matters, here).
Cryptographic weakness on Debian systems Posted May 13, 2008 15:59 UTC (Tue) by hmh (subscriber, #3838) [Link] The key vulnerability check basically hashes the key and searches for it in a blacklist of 256Ki entries. The code says that blacklist is not known to be the complete set of weak keys, it could be just a subset. Further comments of that really means depend on studying the OpenSSL code at depth, which I hope someone will disclose soon.
Cryptographic weakness on Debian systems Posted May 13, 2008 15:17 UTC (Tue) by jond (subscriber, #37669) [Link] Only if PURIFY is defined. I'm not sure in which situations that happens, but I think it's valgrind-related. So the binary packages being distributed are fine.
Cryptographic weakness on Debian systems Posted May 13, 2008 15:50 UTC (Tue) by lambda (subscriber, #40735) [Link] Only if PURIFY is not defined. That line was being excluded from PURIFY because it was causing warnings about uninitialized data.
Cryptographic weakness on Debian systems Posted May 13, 2008 16:22 UTC (Tue) by IkeTo (subscriber, #2122) [Link] > The patch is only half undone. Oversight? Unlikely. The original intent is quite defensible: if some data is not initialized, you don't know whether it is coming from some attacker, so you shouldn't use it as part of the random number to generate your key. I expect that is the part that is left alone, in the function ssleay_rand_bytes. The "#ifndef PURIFY" macro probably is there because some tools detects that it is using uninitialized data, and would die or produce other ugly result if the code is allowed to run. But the patch change another function ssleay_rand_add as well. I'm wondering whether the buf being passed in is actually the data that it want to add to the random pool. If so, the original removal of line 274 probably drops nearly all randomness that the random number generator can ever obtain.
|
|||||||||||||