In regards to this giant fuckup:

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

What exactly is the impact of this vulnerability?

1) Does it let a attacker, who has listening ability on a local
network, to intercept keys? (ie reduce security of SSH to that of telnet)

2) Does it allow an attacker, who does NOT have a listening ability,
to log on to remote machines using known weak keys? (ie brute force a
fully remote machine)

Just what is the extent of this sad story?

As I use ssh and keys a lot, this means that I had to spend a lot of
time fixing all the trust network that I have. I think that I am done,
finally.

--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
http://improve-usenet.org/

Ignoramus17861 wrote:

You'll want to also look at
http://lists.debian.org/debian-security-announce/2008/msg00152.html

It was first introduced on 2006-09-17 in Debian unstable.
If your key-pair was generated on a Debian or derivative system it must be
regenerated. If a DSA key was used on an affected system it must be
regenerated. see: http://www.debian.org/security/key-rollover/

While keys generated with GnuPG or GNUTLS are not effected if they were used
for signing or authentication on an affected system they should be
regenerated. Make new key-pairs, sign with old keys, revoke old keys.

On 2008-05-14, sk8r-365 sk8r.debian.etch.invalid.org> wrote:

"Ignoramus17861" wrote in message
news:mcKdndL0Xr01PbfVnZ2dnUVZ_qzinZ2d@giganews.com...

You should consider this to remove all security of SSH, and any other
program that uses the dev random pool. It isn't quite that bad, but it is
very close.

In comp.security.ssh Ignoramus17861 wrote:
| In regards to this giant fuckup:
|
| http://www.ubuntu.com/usn/usn-612-2
|
| What exactly is the impact of this vulnerability?
|
| 1) Does it let a attacker, who has listening ability on a local
| network, to intercept keys? (ie reduce security of SSH to that of telnet)

The private keys themselves are not sent. The cipher key for the session is.
But I don't know if that key can be reproduced from a session playback once
the blackhat has guessed the authentication key.

| 2) Does it allow an attacker, who does NOT have a listening ability,
| to log on to remote machines using known weak keys? (ie brute force a
| fully remote machine)

Based on what I read, it is the authentication key that may be weak. You
have a fair chance of having generated a weak authentication key. If so,
the blackhat has a fair chance of guessing what that key is, and pretending
to be you to access hosts.

Ignoramus17861 wrote:

Ubuntu has released an update to her version
of openssl-0.9.8e.

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Xubuntu 7.10) Linux 2.6.25.3
^ ^ 19:46:01 up 1 day 3:34 1 user load average: 1.12 1.06 1.02
綜 援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa/

On 2008-05-14, phil-news-nospam@ipal.net ipal.net> wrote:

That's the 64,000 dollar question.

On 2008-05-14, Joseph Ashwood msn.com> wrote:

Ignoramus12901 wrote:

Very nearly.

* If you generated your private key with a broken version of
ssh-keygen then you lose. The attacker can work out your private
key easily and impersonate you to everyone.

* Worse, if you authenticated yourself to anyone using a DSA key using
a broken ssh client, then you lose. The attacker can recover your
private key, and impersonate you as before. This happens regardless
of when the DSA key was generated.

* If your server generated its key with a broken version of ssh-keygen
then you lose. The attacker can impersonate the server and use this
to collect passwords you type in, persuade you to believe in lies or
whatever.

Mark, thanks a lot for a finally, very detailed reply leaving no
questions unanswered. I worked hard last night to upgrade all machines
that are on or near internet and replaced all vulnerable keys.

Do you know if there are any known exploit scripts written to exploit
this vulnerability?

I wrote this shell script to check for keys:

#!/bin/bash

test -d ~myuserid/tmp || mkdir ~myuserid/tmp; chmod 711 ~myuserid/tmp

test -e ~myuserid/tmp/dowkd.pl || (cd ~myuserid/tmp && wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz && gunzip dowkd.pl.gz && chmod 755 dowkd.pl)

chown myuserid ~myuserid/tmp

perl ~myuserid/tmp/dowkd.pl file {/root,/home/*}/.ssh/{*.pub,authorized_keys} | sed s/^/`hostname`:/