Debian Bug Leaves Private SSL/SSH Keys Guessable

SecurityBob writes "Debian package maintainers tend to very often modify the source code of the package they are maintaining so that it better fits into the distribution itself. However, most of the time, their changes are not sent back to upstream for validation, which might cause some tension between upstream developers and Debian packagers. Today, a critical security advisory has been released: a Debian packager modified the source code of OpenSSL back in 2006 so as to remove the seeding of OpenSSL random number generator, which in turns makes cryptographic key material generated on a Debian system guessable. The solution? Upgrade OpenSSL and re-generate all your SSH and SSL keys. This problem not only affects Debian, but also all its derivatives, such as Ubuntu." Reader RichiH also points to Debian's announcement and Ubuntu's announcement.

Comments

2 years?

[Anonymous Coward]

The seeding was removed and it wasn't noticed for TWO YEARS? In a distro as popular as Debian?

Re:2 years?

[jrothwell97]

Hang on. There was a story here the other day about a bug in BSD that had been carried down to all its descendants (FreeBSD, OS X, NetBSD etc) for twenty-five years without anyone noticing. Two years is nothing.

Re:stupid stupid stupid

[mikael]

There was a lawsuit story some time ago about a Las Vegas casino vs. a regular punter, over the use of a blackjack game. The punter had found a cabinet unit with a frazzled RNG, so it kept dealing the same sequence of cards every time. The punter managed to memorize the sequence, thus guaranteeing a win every time. Of course, the casino wasn't too happy about this.

Surely this is not the only source of entropy!

[argent]

Going to http://www.links.org/?p=327 I read...

OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it.

Uninitialised data doesn't seem to be a good source of randomness to depend on, since depending on where it happens you may consistently end up with a buffer that previously contained all zeroes (or some default memory test pattern), the same part of the same shared library header, or a series of stack frames that for whatever reason happen to be the same frames on every run.

In fact I'd expect that separate runs of the same program with the same parameters and environment would leave the same junk on the stack every time.

So I would hope that they have some better source of entropy than unpredictable uninitialized data of dubious randomness.

So if this is really a serious problem, then it seems to me there's already a serious problem in OpenSSH.

Degree of Compromise?

[ewhac]

Does anyone have any back-of-the-envelope calculations as to how badly this compromises existing keys? That is to say, about how long is the brute-force lifetime shortened? If it's been shortened from the age of the known universe to 300 hours, then that's a problem I need to address fairly immediately. OTOH, if it's been shortened to one-quarter the age of the known universe, then I'm not going to deal with this before I've had more coffee...

Schwab

correct me if I'm wrong

[Deanalator]

From this log: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516
It looks like openssl is pulling in "entropy" from uninitialized memory, causing valigrind to complain. The debian maintainer "fixed" this issue by memsetting the buffer to zero.

My question is, wouldn't I see the same behavior using grsecurity to scrub deallocated memory? From what I am seeing, this looks much more like the fault of the openssl team.

Re:It will be fixed

[IamTheRealMike]

He would have been told, but who says he would have cared? This happens all the time, although usually it doesn't result in a giant fucking security hole. I was warning people this sort of thing would happen more than two years ago back when I was working on autopackage. It was entirely predictable.

Having distributors randomly change source code as they package it is fundamentally broken. It cannot ever work. It's not just OpenSSL that's been broken like this. Wine often went through periods in which the Debian packages were completely hosed in subtle ways. It would look like a bug in Wine, but was in fact due to parts of the software "going away", because the Debian packager felt they weren't important enough to be a part of the base install. Pointing out that their change was broken didn't help. The result was many, many hours wasted tracking down non-bugs. Then you go through a giant waste of time trying to get the bug in the packages fixed, and just as you finally get it sorted out, some other distribution introduces some other bug into their packages.

So I got sick of this, and started telling people to avoid their distros packages. Some distributors (especially Debian) took it personally and started childish slanging matches. But really, who cares how "integrated" a program is, if it could have had arbitrary bugs silently introduced? It's just a busted model of software distribution.

Imagine if Microsoft reserved the right to modify any software for Windows in any way it saw fit! Yet that's exactly what Debian (and Fedora and Mandrake and Ubuntu) said to me - they reserve the right to make any modifications they like to the software they ship, and if upstream don't like it, tough luck.

I wonder if they'll re-evaluate that policy in light of this disaster. Probably not.