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.

stupid stupid stupid

Who did this? You don't remove the seeding... stupid

did I mention stupid?

this is how some of the old video games were "broken" despite using "random" numbers, the seed was always the same... leading to the same sequence of events

Re:stupid stupid stupid

Who did this? You don't remove the seeding... stupid

That's what I was thinking too. What kind of idiot makes that sort of change?

Re:stupid stupid stupid

That's funny, I use the exact same seed on my luggage.

Re:stupid stupid stupid

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.

Updated advisory from Ubuntu

Ubuntu got an updated advisory at http://www.ubuntu.com/usn/usn-612-2

Re:Updated advisory from Ubuntu

Linky link link: Updated Advisory with instructions [ubuntu.com]

The big question is..

whether this can possibly be claimed to be an accident *dons tinfoil hat*.

But seriously, removing the code that seeds a random number generator? I can hardly imagine making such a change by accident. I may just lack a sufficiently colorful imagination, though.

(or, before resorting to conspiracy theories, we should probably ask ourselves first, "can this possibly be explained by simple stupidity?"

Re:The big question is..

It was reading from initialized memory to for the seed value, leading to valgrind warnings. See the original Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 [debian.org]

OSS, only as good as the last developer?

First off I'm a big OSS supporter, yada, yada

But the point here is that the freedom that OSS gives you does require you to trust the whole distribution chain. In this case there was an added muppet who did something they shouldn't have thus rendering everything downstream insecure. OSS is great but it required great developers, given that it has take well over a year to get the advisory out it shows that the many eyes piece didn't work here, mainly because the eyes were looking at the original source not the botched packaging job.

The "easy to use" Linux box in the house uses Ubuntu and has this issue and like many people I didn't even think to check that the OpenSSL wasn't the REAL OpenSSL it was OpenSSL with muppet extensions. Maybe there needs to be some form of extension that warns that a package has been modified from its original source code and that the modification was done by "K. Frog" so you can determine whether to trust that package or look back to the source.

Or some sort of voting system on contributors (how very Web 2.0) so you can see how the people who touched your package were rated with the biggest weighting being given to the last person through the code (hand edited by Linus = 5 stars, hand edited by James Gosling = 5 stars, hand edited by the bloke who wrote clippy = 2 stars, hand edited by a bloke who removed a seed generator = 0 stars).

Having the code is great, but this makes me want to know much more about who last edited that code.

Re:OSS, only as good as the last developer?

Ah so if the same thing happened from MSFT but no one noticed it does that mean closed source is better.

No software is perfect. when F/OSS screws up everything including the exact versions of the software where the bug began, until it is fixed is known. You know what/where/when/how, and most of the time why it happened.

With closed source software your considered lucky if you get a patch in a timely fashion.

Personally i would rather know what happened and when too.

What's the hurry?

It was accidentally introduced in 2006... so that's what, another 14 years before it gets moved into 'stable'?

*grin*

How Frakin stupid can you be?

"You fell for one of the classic blunders, the most famous being 'Never get involved in a land war in Asia' but only slightly less well known is 'Don't use poorly seeded pRNGs in cryptographic protocols!' HAHAHAHAHAHHAHAHAHAHHAHAHAHAHAHA!!!!

Re:How Frakin stupid can you be?

BUTTERCUP: Who are you?

MAN IN BLACK: I am no one to be trifled with, that is all you ever need know.

BUTTERCUP: To think -- all that time it was your cryptographic protocol that was poorly seeded.

MAN IN BLACK: They were both poorly seeded. I spent the morning downloading a patch to build an immunity to keys being guessed.

2 years?

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

comics

http://www.random.org/analysis/dilbert.jpg
http://www.xkcd.com/221/

Too early

I realized I probably should be legally required to have a morning cup of coffee before thinking because I am an idiot otherwise.

I wake up and what do I see first thing? That there is a problem with Debian's OpenSSH package and the /. article links to the following code snippet:

def init(pipeline, librarian):
          gst.debug_set_default_threshold(gst.LEVEL_ERROR)
- if gst.element_make_from_uri(gst.URI_SRC, "file://", ""):
+ if gst.element_make_from_uri(
+ gst.URI_SRC,
+ "file:///Sebastian/Droge/please/choke/on/a/bucket/of/cocks", ""):
                  global playlist
                  playlist = PlaylistPlayer(pipeline or "gconfaudiosink", librarian)
                  return playlist

Now I am thinking, "What exactly is going on here? Is choking on a bucket of cocks not a good source of randomness?"

A great filter

Anyone who posts to this story saying that this is no big deal or telling other people to stop whining should simply be banned from Slashdot for life. If you cannot be bothered to read the article and you cannot be bothered to understand just what a serious vulnerability this is but you insist on insulting those who do, why should you be allowed to continue to post your ignorant bleating?

Re:It will be fixed

This problem isn't something you can just update your system to fix. This means the basis for all remote authentication on your Debian/Ubuntu machines is compromised until you go and fix it manually.

Re:It will be fixed

It shouldn't need fixing in the first place.

Debian people screwed up. This leaves a huge distaste in my mouth for Debian (and Ubuntu).

Re:It will be fixed

I'm sure the problem will be fixed if the developers acknowledge that the problem exists. Not a big worry.

No, but it shouldn't have been changed in the first place. Debian needs to stick their ego up their ass sometimes and just let the people who wrote the software do the coding vs. sticking their own code in in places they don't fully understand. This and their attitude of licensing and not reporting changes back upstream is a stupidly annoying habit.

note: When I have to run Linux instead of a BSD it's Debian and/or Kubuntu all the way since the benefits outweigh the negatives, but it's still an annoying habit of theirs.

Re:It will be fixed

I'm sure the problem will be fixed if the developers acknowledge that the problem exists. Not a big worry.

Yes, it is a big worry because any keys generated with this package are now potentially suspect. This means that anybody who's used Debian or a Debian derived distribution like Ubuntu needs to go back and destroy all host and personal keys generated since 2006. All of those keys are potentially guessable.

And that's a real vulnerability. Early versions of Netscape's SSL implementation (the first SSL implementation) were trivially crackable because of just such a vulnerability [berkeley.edu].

Re:It will be fixed

Basic cryptographic services have been compromised for a year and your analysis is to assume on faith that it's open source so it will be fixed, so no problem?

If someone stole your crypto keys and has had them for a year...

How thoroughly might they have compromised your system by now?
How many passwords might they have stolen that you use on other systems?
What else might they have done that will give them access in the future even after you fix this?

Just regenerate your keys and no problem? The problem that guessable keys are generated will undoubtably be fixed asap, if not already. The problem that this has been the case for the last year will not be, and is a big worry.

Re:It will be fixed

Downloading the patch is step one - you also need to regenerate any certificates made with OpenSSL since 2005, since they can't be guaranteed to be secure.

This has the potential to turn into a huge pain in the arse for Debian based shops, who will need to reissue SSL certificates, SSH keys, and a whole host of other essential elements of their security infrastructure.

Re:You stupid god damned open sourcers

Windows here I come. At least someone would be accountable for shit work like this.

Yeah, like all those times when MS cut checks for all their customers whose computers were compromised! Oh, wait...

Re:Of course...

Quit being a cry baby and run 'apt-get upgrade' already. It would have taken you less time than to come in here complain.

... and regenerate all the keys, yes? It isn't quite as simple as you suggest...

"All OpenSSH and X.509 keys generated on such systems must be considered untrustworthy, regardless of the system on which they are used, even after the update has been applied."