Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
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:
The offending change is in two places. Now see the "fix":
The patch is only half undone. Oversight?
Cryptographic weakness on Debian systems
Posted May 13, 2008 15:17 UTC (Tue) by hmh (subscriber, #3838)
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
Posted May 13, 2008 15:59 UTC (Tue) by hmh (subscriber, #3838)
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.
Posted May 13, 2008 15:17 UTC (Tue) by jond (subscriber, #37669)
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.
Posted May 13, 2008 15:50 UTC (Tue) by lambda (subscriber, #40735)
Posted May 13, 2008 16:22 UTC (Tue) by IkeTo (subscriber, #2122)
> 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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds