Fixing Debian OpenSSL

This bug is a nightmare. I had to klutz around on 5 boxes and regenerate ssh keys. I had 3 compromised keys. I worry about all those newbie Ubuntu users though who have little experience of this kind of thing. Hopefully most are running desktops not exposed directly to the internet (i.e. behind a router) or have not activated sshd. Otherwise we could see a big uptick in brute force attacks etc etc...

Not pretty.

My understanding is that the keys were regenerated with the fix Ubuntu provided. My father runs Ubuntu and this is what the update implied...

The degree of nightmare corresponds to however many ssh keys you have floating around in the world, plus however many public keys you have exchanged with other people. Those won't be fixed by any automatic Debianbuntuetc. updates.

The worst case scenario is that those to whom you gave a public key will no longer be able to access your box. Thank goodness my father only exchanged keys with my machine. whew!

Good thing I am using Slackware...

@garymax:

How much do you trust Patrick's trust in OpenSS[LH]?

(My local Slackware source mirror shows no patches in OpenSSH, and only ./Configure adjustments to architecture specs in OpenSSL.)

> The degree of nightmare corresponds to however many ssh keys you have floating around

Exactly. One thing that got me thinking was freenx which I use a lot between boxes. It appears to have its own set of keys for the user nx. They are in /usr/NX/home/nx/.ssh/ I am unclear at present whether the diagnostic tools (the perl one mentioned in the other thread and ssh-vulnkey) check the nx keys or not....

gus3

The issue was with a Debian-based number generator for one. Secondly, Patrick does not patch upstream source code. So if there were a vulnerability the original upstream developers would have found it and patched it before now.

Steven J. Vaugh-Nichols has a great post on his web site about this vulnerability. Among his astute observations is that Debian takes upstream and "forks" the code to a certain extent. Then they keep the code to themselves. This is one reason why the vulnerability has lasted this long.

SJVN said the following:

"You see Debian developers have this cute habit of keeping their changes to themselves rather than passing them upstream to any program’s actual maintainers. Essentially, what Debian ends up doing is forking programs. There’s the Debian version and then there’s the real version."

In contrast, Slackware uses upstream source with little or no patches. It has proved secure thus far. It isn't a Patrick Volkerding (The Man!) thing; it's about code transparency vs forking.

So, yes, I trust Slackware.

@garymax

not at all (wrt keys being regenerated)

any keys generated by the affected ububtu systems must be found and regenerated ... the update does not say that only installing the update is the only thing required.

http://www.ubuntu.com/usn/usn-612-2

In fact is says:

Check all OpenSSH user keys.

It includes a tool to help ... but it only looks in known places.

To answer my own question here is the security advisory from nomachines regarding nx

http://www.nomachine.com/news-read.php?idnews=237

To my chagrin I found 3 MORE compromised keys.

There is a huge (incomplete) list of affected secondary applications on the Debian wiki.

What a mess!

hughesjr

Understand about keys issued to others but I only had one machine with Ubuntu on it and it belongs to my father. What I had reference to was the keys on your own machine--they were regenerated by the update.

I agree that any keys issued by the affected machine would have to be discarded and regenerated.

> Secondly, Patrick does not patch upstream source code.

To be fair, I think it's more accurate to say that Patrick patches upstream source code only when absolutely necessary.

Which is pretty much what you said later on.

jdixon

My oversight. Patrick certainly does when it needs to be done for a stable system. Thanks for catching that and covering for a fellow Slacker! :-)

I did an update today, SSL was updated and a "bad key" package came along too.

The system ssh keys were regenerated.

So it looks good. Sadly, in "stable", that additional blacklist package cannot be added. I'm sure they'll find a way.

I updated and the system keys were regenerated as well and the blacklist package installed. However when I ran the diagnostic program

http://security.debian.org/project/extra/dowkd/dowkd.pl.gz

A bunch of (personal not system) compromised keys showed up.

debian wiki has info about running that diagnostic: http://wiki.debian.org/SSLkeys

Quoting:Sadly, in "stable", that additional blacklist package cannot be added.

Eh? Sure it can. And it has. Just do "apt-get dist-upgrade" instead of "apt-get upgrade".

I think the problem is that if a regular apt-get update apt-get upgrade doesn't fix everything, a lot of people who aren't following the issue on the blogs won't know that they have a problem with compromised keys.

The debian updater which virtually all desktop people use complains very loudly that it cannot install the update and that you have to use Synaptic to "mark all updates". If you do that, you'll get the blacklist pacage. So, I think most regular desktop folk will get the package and the new keys.

What I meant is, "stable" is only supposed to get package updates, not new packages.

Hopefully, the Debian team will violate that rule and mark them as new, required packages, so that even with an "apt-get upgrade" the new package will be installed. Nothing will be deleted.

The real use of "dist-upgrade" is that it will automatically delete conflicted obsolete packages.

Debian stable also gets "important updates", not only plain security patches. I don't think they need to violate any rules :)