Security problem in Debian 4.0 Etch's openssl

[Tseng]

Hi guys,

just wanted to inform you of a very critical security problem in Debian Etch's openssl package. Detailed information can be found in the mailing list and in my own blog (german)

In short:

Code:

# apt-get update       //update packagelists
# apt-get upgrade -f   //force ugrades

Then you should actually restart the system, so all relevant services will use the new openssl version.

Now go and update



EDIT: in response to rbtux's comment, you should checkout the following:

- http://www.us.debian.org/security/key-rollover/
- http://wiki.debian.org/SSLkeys

[rbtux]

STOP...

Please don't post it that way Tseng. We now about the security problem but updating and restarting the server is not enough. You have to reissue all the keys generated with the broken SSL version. (And be sure you can still connect through your ssh BEFORE you restart the server ;-)

[Tseng]

I edited my first post. Sorry, for not mentioning something that important. But rbtux is right. Be sure you can still connect to your server via ssh before restarting.

[Kika]

This is not enough, you must run these commands after upgrade because that was a CERT vulnerability bug:

Code:

# rm /etc/ssh/ssh_host_*
# dpkg-reconfigure openssh-server

[Quemeros]

I'm noob with debian, and my question of this is...
this sec problem fix with the 4 lines posted before, but, how can i be sure that will can still connect to my server via ssh before restarting?

[kilburn]

Just restart the daemon and try to open a new ssh session, if it works you can connect

[FeG]

Hi guys,

it's also important to mention that all keys generated since september 2006 should be considered compromised. You have to regenerate all SSH and SSL keys (i.e. keys used for private/public-key authentication with ssh or ssl keys for apache, postfix, etc.).

You might also want to have a look on the related Debian Security Advisory.

Greetings
FeG

[Quemeros]

kilburn Wrote:Just restart the daemon and try to open a new ssh session, if it works you can connect

You don't answer anything, im not stupid -.-... If not i will lost my unique way to conect to the OS (Because i don't have physic acces to it)... What recomend me to do? install telnet? or how to be sure before restart?

[rbtux]

Quemeros Wrote:

kilburn Wrote:Just restart the daemon and try to open a new ssh session, if it works you can connect

You don't answer anything, im not stupid -.-... If not i will lost my unique way to conect to the OS (Because i don't have physic acces to it)... What recomend me to do? install telnet? or how to be sure before restart?

If you restart sshd the sessions normally aren't cleared. So when you are able to login again with a new session all worked well. I got phys and serial acces to all our servers so I don't have any experience doing that over ssh. But I wouldn't generate and exchange keys over an insecure (meaning telnet) connection. You may want to start another sshd instance (different port) instead.

[ispcomm]

Quemeros Wrote:You don't answer anything, im not stupid -.-... If not i will lost my unique way to conect to the OS (Because i don't have physic acces to it)... What recomend me to do? install telnet? or how to be sure before restart?

I've been lurking this thread as it's not ispcp related (not even close) and I didn't want to inflate it. But I can't stand when I see an attitude like yours. Judging from your last posts, you might well be what you think you're not. Respecting the others and doing your homework is the minimum you need to do. Kilburn answered properly in the first place. It was you that didn't get it. Being harsh as an answer was less than appropriate from your side and he's been too kind to actually explain what he meant instead of just passing by and forgetting about you.

I don't want to flame you. I'm just making sure you understand how lucky you are.

ispcomm.