Debian and the OpenSSL PRNG

Searching for Weak Debian / Ubuntu SSL Certificates

Tales from the Crypto — Fri, 23 May 2008 04:45:50 GMT

I've seen a number of people promote packages that have shipped for Debian and Ubuntu, which allow

re: Debian and the OpenSSL PRNG

Alun Jones — Wed, 21 May 2008 03:59:15 GMT

Actually, it didn't really require much knowledge of crypto to realise that something was wrong with the change made by the Debian folks.

It's clear that a buffer is passed in to this function to "add" it to something in a crypto function - once out of several times, the buffer comes from uninitialised memory, and this is what caused the Purify / Valgrind errors.

If the Debian guys had simply 'fixed' the one call that supplied uninitialised data, life wouldn't have been so bad. Instead of fixing the call, they fixed the function, so that the function essentially did nothing with its main parameter.

That should have been a clue that they were neutering an important operation of the function.

A little knowledge is clearly a dangerous thing.

re: Debian and the OpenSSL PRNG

Aaron Margosis — Wed, 21 May 2008 02:56:12 GMT

Ya wrote:

> At least if you have the source code, and are insanely motivated, you can find out what the truth of a matter is.

??? The Debian guys had the source code. Is insane motivation enough? Doesn't it also require deep knowledge of cryptography to be able to divine anything resembling "truth" here? If you have the source and the ability to modify it, chances are much better than you'll do something that will someday end up in an Alun Jones blog post. :)

re: Debian and the OpenSSL PRNG

Harry Johnston — Wed, 21 May 2008 00:30:46 GMT

OK, that makes more sense than my version. On the other hand, it means it was an even sillier mistake than I originally thought!

re: Debian and the OpenSSL PRNG

Kieran — Tue, 20 May 2008 13:55:56 GMT

From my reading the only source of entropy was the process id, all others would be ignored. Is this thinking correct?

Once that line had been removed, yes, the only entropy being added by the call to ssleay_rand_add was the PID, which usually numbers under 32,768.

re: Debian and the OpenSSL PRNG

Alun Jones — Tue, 20 May 2008 04:16:39 GMT

You are right. I have the story wrong.

There were two lines of code - one from the seed function, and one from the function that, as you say, adds entropy of the calling program's choosing. The latter is still an issue - a program that encrypts using known values and a user's chosen entropy is no good if it ignores the entropy.

However, the part that's the big deal here is the line in the "add random bytes to seed" function.

So my description is wrong - instead of removing the small uninitialised buffer entropy only, the seed function removed all sources of entropy - even on machines with dedicated hardware random number generators!

Every time a piece of code said "here's some entropy to add to the seed to make it more random", the function said "I'm not touching that, it might be uninitialised".

Contrary to my earlier assertion, then, if you generated a key on OpenSSL or any program that called OpenSSL, on a Debian Linux or derivative build, your keys are weak and must be regenerated.

It's unconscionable that someone would check in this code, and that noone of the "many eyeballs" noticed it.

re: Debian and the OpenSSL PRNG

davidw — Mon, 19 May 2008 08:36:22 GMT

You have the story wrong:

The Debian guy commented out two lines of code. One of those directly added contents of an uninitialized buffer to the pool, stirring things up slightly.

But he also commented out another line, with far more drastic consequences. It seems that there is a function in the code that provides the major source of randomness. The Debian guy also commented out the line of code that adds the output of this function to the pool.

See

http://www.links.org/?p=328

re: Debian and the OpenSSL PRNG

Harry Johnston — Mon, 19 May 2008 01:00:00 GMT

"Other sources of entropy would have increased the number of possible keys, wouldn't they?"

Originally, yes; but the code change in question prevented not only the uninitialized data from being included in the seed but also all the other sources of entropy included in the original algorithm (except the PID).

I assume the code looked something like this, although of course not as obvious:

char buffer[buf_size];

while (some-condition) {

insert-entropy-into-prng(&buffer);

get-some-entropy(&buffer);

}

and the change made was equivalent to removing the call to insert-entropy-into-prng. (!)

Once again, for emphasis - this is based on what I've previously read about the issue, I may have been misinformed or have misinterpreted it.

re: Debian and the OpenSSL PRNG

Alun Jones — Sun, 18 May 2008 23:46:37 GMT

Other sources of entropy would have increased the number of possible keys, wouldn't they?

As I acknowledged in my article, there are other sources of entropy - a file containing a random seed, or the random device. However, the random device isn't there on all machines, and a user may not care about creating a random seed file. In such base configurations, it appears, all you get is the PID and the uninitialised data.

If there were more entropy than that, HD Moore's keys wouldn't work, would they?

re: Debian and the OpenSSL PRNG

Harry Johnston — Sun, 18 May 2008 21:29:40 GMT

I don't know this for a fact, but my understanding is that the line of code that was incorrectly removed was only using uninitialized data on the first iteration. On the remaining iterations it was adding various other sources of entropy.