Random Number Bug in Debian Linux (2008) | Hacker News Reader

Random Number Bug in Debian Linux (2008)

schneier.com

38 pointspdknsk13 comments

Two obligatory links.

1. Debian dev on the openssl mailing list if he can remove the code causing errors in Valgrind: http://marc.info/?l=openssl-dev&m=114651085826293&w=2

2. Developer with a @openssl.org email address giving him the green light: http://marc.info/?l=openssl-dev&m=114652287210110&w=2

Source: http://lwn.net/Articles/282038/

Also:

1. The commit introducing the bug: "Don't add uninitialised data to the random number generator. This stop valgrind from giving error messages in unrelated code." http://anonscm.debian.org/viewvc/pkg-openssl/openssl/trunk/r...

2. The commit fixing the bug: "ssleay_rand_add() really needs to call MD_Update() for buf." http://anonscm.debian.org/viewvc/pkg-openssl/openssl/trunk/c...

(I'd post the diffs but viewvc is throwing exceptions for them)

Nothing has ever quite degraded my opinion of the Debian project as much as the fact that everybody is quoting that in order to shift blame instead of them trying to debug their process for patching security-essential code.

The only thing that it means is that the security team does not fully understand the code it maintain, and apparently the same can be said about the openssl team. As a user myself, I don't understand that code, but I rely on people who should. Perhaps it means that the Debian security team should get more knowledgeable people onboard, but knowledge is also made of experience, and requires time to build up. Hopefully this will become a valuable experience for everyone, I know it has for me.

By the way, does anyone know of a certified SSL stack (a la compcert)?

Someone replied pointing out the correct solution (build with -DPURIFY) a few hours later [1], but I think the Debian developer in question was too young to understand what Purify is or why that's the correct approach.

[1] http://marc.info/?l=openssl-dev&m=114654760312453&w=2

Edit: also, the Debian developer didn't actually identify himself as such on the mailing list, or I have a feeling people would've scrutinized what he was suggesting a lot more closely.

Last sentence of the article:

"Random numbers are used everywhere in cryptography, for both short- and long-term security. And, as we've seen here, security flaws in random number generators are really easy to accidently create and really hard to discover after the fact. Back when the NSA was routinely weakening commercial cryptography, their favorite technique was reducing the entropy of the random number generator."

Consider that the article is from 2008 and correlate it to the current revelations about NSA.

I guess it is really hard to write a test suite that would catch these types of weaknesses?

PS Just noticed this is from 2008 (whew, I was afraid it had happened again).

This is ancient news, and it seemed to be sufficiently explained as really silly human error. However your comment reminded me of a Dilbert-

http://dilbert.com/strips/comic/2001-10-25/

While we're talking comics, this xkcd comic was inspired by this particular debian bug: http://xkcd.com/221/

As a more serious note, people who are not cryptographers should refrain from touching crypto code, especially something as important as pseudo random number generators. In addition, it's not a very good idea be doing significant modifications "downstream" from the actual project.

Stupendously hard. I mean, it wouldn't be too hard to write a test case for this one bug after you already wrote the bug and knew what you were looking for. Write a test case that runs this code multiple times and checks for duplicate outputs. If I recall the nature of this bug correctly, two runs in the same process would be enough. If not, some tens of thousands of runs would do. However, problems: A) you wouldn't know to write a test case like this until the bug happened, and B) this test won't catch similar serious bugs, such as a bug that causes the random number generator to be limited to, say, 32 bits of entropy.

This article is five years old; it'd be nice to note that in the title.

Note this is from 2008.

Read the last sentence.

Reply on news.ycombinator.com