Critical security update for openssl
Posted by Steve on Tue 13 May 2008 at 14:37
A new security advisory has recently been released relating to the Debian openssl package, and whilst most security updates are not news-worthy this one is. Read on for a brief overview of the problem.
The actual security announcement may be found here:
Quoting that announcement:
Luciano Bello discovered that the random number generator in Debian's openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable.
This is a Debian-specific vulnerability which does not affect other operating systems which are not based on Debian. However, other systems can be indirectly affected if weak keys are imported into them.
It is strongly recommended that all cryptographic key material which has been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems is recreated from scratch. Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.
What does this mean?
What does this mean? It means, in short, that if you've generated SSH keys for logining into remote systems, and you've generated those keys upon a Debian etch system then people might be able to connect to that system, as you, without knowing the private part of the key.
Because the key-generation process was broken the keys are not as strong as they should be - to the extent that a brute-force attack is feasible.
What can you do to fix this?
There are two parts to this problem, and thus two solutions.
The first thing to do is to apply the security update. This will ensure that any future keys generated will be secure.
The harder step is to ensure that you've replaced any keys which you might have previously created.
Where can you learn more?
The Debian security site will contain more details, updating as required, at the following link:
[ Parent | Reply to this comment ]
Hello,
The announcement explains that the only concerned distribution is etch and sarge was not concerned :
The first vulnerable version, 0.9.8c-1, was uploaded to the unstable distribution on 2006-09-17, and has since propagated to the testing and current stable (etch) distributions. The old stable distribution (sarge) is not affected.
Olivier;
[ Parent | Reply to this comment ]
The first vulnerable version, 0.9.8c-1, was uploaded to the unstable distribution on 2006-09-17, and has since propagated to the testing and current stable (etch) distributions. The old stable distribution (sarge) is not affected.
So here we go. Looks like Sarge users are safe.
[ Parent | Reply to this comment ]
However other distros such as Ubuntu that are based on Debian Etch or later may also be affected, so you may need to check any non Debian systems.
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Give it time and it will appear.
[ Parent | Reply to this comment ]
You can manually generate new SSH keys if you want to, from my LUG someone suggested:
- Install the update.
- Delete the following files:
~/.ssh/id_*
~/.ssh/authorized_keys
/etc/ssh/ssh_host_dsa_key*
/etc/ssh/ssh_host_rsa_key*
- Generate new host keys:
sudo dpkg-reconfigure -plow openssh-server
- Generate new personal keys:
ssh-keygen -t rsa -b 4096
- Restart the ssh daemon
Do this on all machines. Don't log out after deleting the host keys
(in /etc/ssh) as you won't be able to log back in by ssh.
As a precaution, I've also been regenerating the DH key exchange
moduli, which are kept in /etc/ssh/moduli. That's documented near the
bottom of the ssh-keygen man page.
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
> (in /etc/ssh) as you won't be able to log back in by ssh.
This is the bit that worries me, as I have a remote machine that needs upgrading and getting it wrong would involve an expensive journey and a wasted day. So you're suggesting that having installed the new openssl package, I should (over ssh)
# rm /etc/ssh/ssh/ssh_host_*
# dpkg-reconfigure -plow openssh-server
(Will that ask questions? What should I answer?)
# /etc/init.d/ssh restart
I have to hope that I don't suffer any sort of interruption while doing all that.
So, is there any way to do this more safely? Are these the only critical steps, from the point of view of not locking myself out of the machine?
Phil.
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Probably too late now - but yes those are the steps that you need to take.
In the past for times like this I've configured telnetd to run, in case of problems. But that is probably overkill - "sshd restart" won't drop existing connections.
[ Parent | Reply to this comment ]
Basically delete your old keys and generate new ones.
It also explains ssh-vulnkey which once installed prevents you from using insecure keys altogether. Don't install and enable this on a remote machine until you are happy that your new safe keys work.
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
I haven't used it (I'm doing everything from scratch), but it can be useful to some of you.
[ Parent | Reply to this comment ]
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
The solution is probably going to be obvious once I find it.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
ii libssl0.9.8 0.9.8e-5
ii openssh-blacklist 0.1.1
ii openssh-client 1:4.3p2-9etch2
ii openssh-server 1:4.3p2-9etch2
ii openssl 0.9.8e-5
aptitude purge libssl0.9.7 doesn't sort it, although it did clear the removed copy of libssl0.9.7 that had been left by aptitude.
Repeated reboots don't sort it - these after removing the aforementioned libs, just in case they were opened by something and hence still being used.
rm /etc/ssh/ssh_host*; dpkg-reconfigure -plow openssh-server; doesn't sort it; either before or after any of the steps listed above.
You tell me: how do I persuade etch to generate host keys that aren't pre-compromised, at least according to ssh-vulnkey and sshd (when it starts)?
[ Parent | Reply to this comment ]
Using aptitude or pinning to revert fixed it. :-/
[ Parent | Reply to this comment ]
Also, the new libssl installed without any mention of the necessity for key regeneration. That appears to be a serious omission.
[ Parent | Reply to this comment ]
I thought the same thing. I was happy to see, however, a warning message when upgrading two of my machines running Ubuntu 8.04. No mention, like you said, when upgrading on Debian.
Anyone else has some input on this?
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Also, answering my own question I found on that page:
Note that dowkd.pl produces many false positives and that the authors suggest that it may also produce false negatives. On that basis, you might decide that it is simply easier to regenerate your keys as described above.
[ Parent | Reply to this comment ]
Ooops
Made the mistake yesterday of updating a remote server (etch) with the new ssh deamon without turning on passwords first.
With
PasswordAuthentication nothe new server started. I was aware of that there were some blacklist tools but I had not read properly how that would work. I figured I'd better update get the new key generation tools to be able to create good keys.
So the new ssh server starts, and promptly blacklist my key. Now I am locked out of the system. Catch ? the server is located 1,283 km from me, by a windows savy friend. I hope he can help me with editing the sshd_config, with.. vi.
And also. Once I get access to the box again. I need to regenerate all new certificates, from my selfmade CA to all certs. Are there any pointers to how to do this in the propper way ? Expiring the CA and the keys. Well will have to do some reading up on certs again.
[ Parent | Reply to this comment ]
In one session you do the work, the second session is open for fallback purpose.
When you are done with the new sshd_config or keygeneration, you can restart the deamon. With a third session you try to login. If it fails, you still have two sessions open.
I always run important scripts, which would break something on interruption, with screen.
sorry, no hint for your CA problem.
7horsten
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
The wiki and issue page are now on-line and list all the applications you'll need to regenerate your keys for.
http://www.debian.org/security/key-rollover/
and
http://wiki.debian.org/SSLkeys
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
see below what I mean
hraklhs:~# aptitude upgrade
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
Building tag database... Done
The following packages have been kept back:
openssh-client openssh-server
0 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
hraklhs:~# aptitude dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
Building tag database... Done
The following NEW packages will be automatically installed:
openssh-blacklist
The following NEW packages will be installed:
openssh-blacklist
The following packages will be upgraded:
openssh-client openssh-server
2 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 3007kB of archives. After unpacking 4293kB will be used.
Do you want to continue? [Y/n/?] n
Abort.
[ Parent | Reply to this comment ]
- hayalci
[ Parent | Reply to this comment ]
thanks for the explanation
[ Parent | Reply to this comment ]
http://www.links.org/?p=327
http://www.links.org/?p=328
His language is perhaps inflammatory but good points are made, both by Ben and by some of the commentators.
[ Parent | Reply to this comment ]