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

Re:Many eyes make all bugs shallow

[n0dna]

http://en.wikipedia.org/wiki/Linus's_law

I understand he's not unheard of in this arena.

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:correct me if I'm wrong

[hackstraw]

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.

If you look further down the code, it then fills up the buffer with stuff from some random device (/dev/random /dev/urandom, or other things found in ./configure).

AFAIK, all modern Linux implementations have /dev/urandom and isn't that enough entropy for a seed?

I only spent a minute looking that the code and the diff in the parent's post, but this is looking not to be a bug to me. But, like I said that I didn't look at the code that long, but I don't see where memsetting the memory makes any difference if its all being overwritten.

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.

Kurt Roeckx (debian) mail to openssl-dev list

[omz]

Found this post at openssl-dev list by Kurt Roeckx ( AFAIK the Debian OpenSSL Team member that made this RNG-clean patch )

http://www.mail-archive.com/openssl-dev@openssl.org/msg21156.html

Extract:

"What I currently see as best option is to actually comment out those 2 lines of code. But I have no idea what effect this really has on the RNG. The only effect I see is that the pool might receive less entropy. But on the other hand, I'm not even sure how much entropy some unitialised data has.

What do you people think about removing those 2 lines of code?

Kurt

"

BTW, i thought that Debian had some kind of policies about testing each package before committing changes in testing/stable branches. Also, the following paper, contributed by another poster, says interesting things about touching cryptographic code, we have to learn from this experience and have tighter policies !

" In a narrow sense, the security flaw we found in the Netscape browser serves merely as an anecdote to emphasize the difficulty of generating cryptographically strong random numbers. But there's a broader moral to the story. The security community has painfully learned that small bugs in a security-critical module of a software system can have serious consequences, and that such errors are easy to commit. The only way to catch these mistakes is to expose the source code to scrutiny by security experts.

Peer review is essential to the development of any secure software. Netscape did not encourage outside auditing or peer review of its software-and that goes against everything the security industry has learned from past mistakes. By extension, without peer review and intense outside scrutiny of Netscape's software at the source-code level, there is simply no way consumers can know where there will be future security problems with Netscape's products. "

http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html"

I have an eCommerce site

[an.echte.trilingue]

I am going to hijack this thread because I have an eCommerce site hosted on Debian and this made me nervous.

According to the reps at Thawte, if you are using a third party ssl cert (thawte, verisign, etc), this does not affect you. According to them, this is only dangerous for people who have generated their own SSL certs for their sites from the ground up (probably a minority, I would guess). If anybody has any information to the contrary, please let me know.

Re:I have an eCommerce site

[Mysteray]

https/ssl/tls/ssh etc use the certificates to agree on a conventional "session key" every time you connect. Session keys are typically chosen with strong random numbers... but if either the client or server is using the OpenSSL from Debian Etch, there's nearly no randomness in it.

Even if your certs are fine, individual transactions are likely vulnerable.

If someone has taken packet captures, they will likely be able to decrypt them retro-actively.