Feverishly pounding upon a keyboard Ignoramus17861 typed:
> In regards to this giant ****up:
>
> http://www.ubuntu.com/usn/usn-612-2
>
> What exactly is the impact of this vulnerability?


"A weakness has been discovered in the random number generator used by
OpenSSL on Debian and Ubuntu systems. As a result of this weakness,
certain encryption keys are much more common than they should be, such
that an attacker could guess the key through a brute-force attack given
minimal knowledge of the system. This particularly affects the use of
encryption keys in OpenSSH."

Follow the instructions from the URL you provided:

"Once the update is applied, weak user keys will be automatically
rejected where possible (though they cannot be detected in all cases).
If you are using such keys for user authentication, they will
immediately stop working and will need to be replaced (see step 3)."

And be sure you have strong keys.

--
sk8r-365
Then began he to upbraid the cities wherein most of his mighty
works were done, because they repented not: -- Matthew 11:20

Ignoramus17861 wrote:

> In regards to this giant ****up:
>
> http://www.ubuntu.com/usn/usn-612-2
You'll want to also look at
http://lists.debian.org/debian-secur.../msg00152.html

>
> What exactly is the impact of this vulnerability?
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.
>
> 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)

No. An attacker can not compromise the system just by sniffing traffic.
When a public key is available a bruteforce against how the private key was
generated is possible. When a client connects to a host it receives a copy
of the public key. Any one who can connect to an affected host or listen to
the connection, even if they can't log on, could break the keys by
bruteforce attacking the badly limited entropy pool used to generte the
keys instead of the keys themselves. An attacker may then impersonate the
host.

Personal keys generated on, and or DSA keys used from, an affected system
are also vulnerable.
> 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)
No, but they may be able to compromise the host key and impersonate the
host. Also DSA keys used from affected systemsmay be able to be
compromised.
>
> 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.
>

See also:
http://it.slashdot.org/article.pl?sid=08/05/13/1533212
http://www.theregister.co.uk/2008/05...n_openssl_bug/

On 2008-05-14, sk8r-365 wrote:
> Feverishly pounding upon a keyboard Ignoramus17861 typed:
>> In regards to this giant ****up:
>>
>> http://www.ubuntu.com/usn/usn-612-2
>>
>> What exactly is the impact of this vulnerability?
>
>
> "A weakness has been discovered in the random number generator used by
> OpenSSL on Debian and Ubuntu systems. As a result of this weakness,
> certain encryption keys are much more common than they should be, such
> that an attacker could guess the key through a brute-force attack given
> minimal knowledge of the system. This particularly affects the use of
> encryption keys in OpenSSH."
>
> Follow the instructions from the URL you provided:
>
> "Once the update is applied, weak user keys will be automatically
> rejected where possible (though they cannot be detected in all cases).
> If you are using such keys for user authentication, they will
> immediately stop working and will need to be replaced (see step 3)."
>
> And be sure you have strong keys.
>

Well, my question was, what opportunities for attackes does this
provide?

Let's say that I often ssh from alice.example.com to bob.example.com
using authorized_keys, and the attacker is able to read the encrypted
traffic.

Would the attacker be able to guess my keys and log on to
bob.example.com?

--
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 in message
news:mcKdndL0Xr01PbfVnZ2dnUVZ_qzinZ2d@giganews.com ...
>> "A weakness has been discovered in the random number generator used by
>> OpenSSL on Debian and Ubuntu systems. As a result of this weakness,
>> certain encryption keys are much more common than they should be, such
>> that an attacker could guess the key through a brute-force attack given
>> minimal knowledge of the system. This particularly affects the use of
>> encryption keys in OpenSSH."

> Well, my question was, what opportunities for attackes does this
> provide?

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.

>
> Let's say that I often ssh from alice.example.com to bob.example.com
> using authorized_keys, and the attacker is able to read the encrypted
> traffic.
>
> Would the attacker be able to guess my keys and log on to
> bob.example.com?

If bob.example.com uses the compromised implementation then the attacker can
do anything. The attacker can impersonate bob, the attacker can read all
messages sent to bob, the attacker can go back and read any recorded
transactions. Basically any trusted communication to or from bob is
completely compromised.
Joe

In comp.security.ssh Ignoramus17861 wrote:
| In regards to this giant ****up:
|
| 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.


| 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.

That depends on where/how you generated your keys.

FYI, I regenerate all new authentication keys more than once a year. Maybe
you should do that, too. I don't do it for fear that my keys have been
compromised. In fact, doing this may actually increase that exposure a tiny
bit. Instead, I do it to "keep in practice", so I don't forget all the steps
I need to do to update everything. I don't want to be in a situation where
I suddenly _need_ to do this and have forgotten what all I need to do to
carry it out correctly.

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

Ignoramus17861 wrote:
> In regards to this giant ****up:
>
> http://www.ubuntu.com/usn/usn-612-2

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_...ub_addressesa/

On 2008-05-14, phil-news-nospam@ipal.net wrote:
> In comp.security.ssh Ignoramus17861 wrote:
>| In regards to this giant ****up:
>|
>| 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.

That's the 64,000 dollar question.

>
>| 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.

Yes.

> 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.

OK. I see.

>
>| 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.
>
> That depends on where/how you generated your keys.
>
> FYI, I regenerate all new authentication keys more than once a year. Maybe
> you should do that, too. I don't do it for fear that my keys have been
> compromised. In fact, doing this may actually increase that exposure a tiny
> bit. Instead, I do it to "keep in practice", so I don't forget all the steps
> I need to do to update everything. I don't want to be in a situation where
> I suddenly _need_ to do this and have forgotten what all I need to do to
> carry it out correctly.
>

I think that I will try to write a authorized_hosts regenerator based
on current public user key database.

--
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/

On 2008-05-14, Joseph Ashwood wrote:
> "Ignoramus17861" wrote in message
> news:mcKdndL0Xr01PbfVnZ2dnUVZ_qzinZ2d@giganews.com ...
>>> "A weakness has been discovered in the random number generator used by
>>> OpenSSL on Debian and Ubuntu systems. As a result of this weakness,
>>> certain encryption keys are much more common than they should be, such
>>> that an attacker could guess the key through a brute-force attack given
>>> minimal knowledge of the system. This particularly affects the use of
>>> encryption keys in OpenSSH."
>
>> Well, my question was, what opportunities for attackes does this
>> provide?
>
> 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.

What do you mean, "remove all security of SSH".

Do you mean that this mistake fully undermined SSH security?

>>
>> Let's say that I often ssh from alice.example.com to bob.example.com
>> using authorized_keys, and the attacker is able to read the encrypted
>> traffic.
>>
>> Would the attacker be able to guess my keys and log on to
>> bob.example.com?
>
> If bob.example.com uses the compromised implementation then the attacker can
> do anything. The attacker can impersonate bob, the attacker can read all
> messages sent to bob, the attacker can go back and read any recorded
> transactions. Basically any trusted communication to or from bob is
> completely compromised.
> Joe
>

And, even more specifically, an attacker who knows a permitted
username, could log on as that username and do anything?

--
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/

Ignoramus12901 wrote:

> What do you mean, "remove all security of SSH".
>
> Do you mean that this mistake fully undermined SSH security?

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.

* And similarly, if the server authenticated itself using a DSA key
using a broken sshd then you lose. The attacker can recover the
server public key, with consequences as above. This happens
regardless of when the DSA key was generated.

* If /either/ the client or server is broken then you lose that
particular session. The attacker has a good chance to work out the
session key, decrypt all the traffic (even retrospectively, if he
kept records) and to hijack your session (i.e., pretend to be you to
the server and pretend to be the server to you, but in real time
only).

If you are even slightly affected by the bug, I strongly recommend:

* Generate fresh SSH private keys and redistribute them.

* If you maintain a server, regenerate at least the its DSA keys (and
send PGP-signed email to your users listing the new keys).

I don't think it's worth taking chances on this one.

> And, even more specifically, an attacker who knows a permitted
> username, could log on as that username and do anything?

Only if he has managed to compromise the user's private key or break
into an existing session.

-- [mdw]

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/e...kd/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`:/

Ignoramus12901 wrote:

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

I'm afraid I don't. Anyone else?

-- [mdw]

Ignoramus17861 illuminated alt.os.linux.ubuntu by typing:
> In regards to this giant ****up:
>
> 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.

Funny really. My system had been updated before you posted this.

The Dev team patch before the security issue becomes common knowledge.

OK. Everyone reading this, if you haven't run update manager
recently, do so now.

--
Moog

"The G is for the gnarled face of someone who's on ninety thousand
pounds a week who reckoned he should have had a throw in"

On 2008-05-14, Moog wrote:
> Ignoramus17861 illuminated alt.os.linux.ubuntu by typing:
>> In regards to this giant ****up:
>>
>> 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.
>
> Funny really. My system had been updated before you posted this.

But that is not enough if you have generated weak SSH keys.

You need to find and delete/regenerate those keys.

i

> The Dev team patch before the security issue becomes common knowledge.
>
> OK. Everyone reading this, if you haven't run update manager
> recently, do so now.
>

--
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/

Ignoramus12901 illuminated alt.os.linux.ubuntu by typing:
> On 2008-05-14, Moog wrote:
>> Ignoramus17861 illuminated alt.os.linux.ubuntu by typing:
>>> In regards to this giant ****up:
>>>
>>> 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.
>>
>> Funny really. My system had been updated before you posted this.
>
> But that is not enough if you have generated weak SSH keys.
>
> You need to find and delete/regenerate those keys.
>
> i

The patch does this. You have no choice.


--
Moog

"The G is for the gnarled face of someone who's on ninety thousand
pounds a week who reckoned he should have had a throw in"

On 2008-05-14, Moog wrote:
> Ignoramus12901 illuminated alt.os.linux.ubuntu by typing:
>> On 2008-05-14, Moog wrote:
>>> Ignoramus17861 illuminated alt.os.linux.ubuntu by typing:
>>>> In regards to this giant ****up:
>>>>
>>>> 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.
>>>
>>> Funny really. My system had been updated before you posted this.
>>
>> But that is not enough if you have generated weak SSH keys.
>>
>> You need to find and delete/regenerate those keys.
>>
>> i
>
> The patch does this. You have no choice.
>

WRONG.

The patch regenerates host keys, but not your private keys.

It also does not delete weak keys that you uploaded to your other
computers and added to authorized_keys.

It would be good to re-read the notice very closely, as your security
is very much at risk if you make just one mistake.

--
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/

Ignoramus12901 writes:
> Do you know if there are any known exploit scripts written to exploit
> this vulnerability?

Given the amount of hammering my SSH ports are getting, I
reckon that somebody has one!

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

On 2008-05-15, Phil Carmody wrote:
> Ignoramus12901 writes:
>> Do you know if there are any known exploit scripts written to exploit
>> this vulnerability?
>
> Given the amount of hammering my SSH ports are getting, I
> reckon that somebody has one!

At least some of that hammering is due to old brute forcing dictionary
scripts.

Ie login as root with passwords root, toor, r00t, t00r, root1, ... etc.

--
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/

Ignoramus12901 writes:
> On 2008-05-15, Phil Carmody wrote:
>> Ignoramus12901 writes:
>>> Do you know if there are any known exploit scripts written to exploit
>>> this vulnerability?
>>
>> Given the amount of hammering my SSH ports are getting, I
>> reckon that somebody has one!
>
> At least some of that hammering is due to old brute forcing dictionary
> scripts.
>
> Ie login as root with passwords root, toor, r00t, t00r, root1, ... etc.

Yup, on one briefly mis-configured machine, I was actually opening
the port to them, and could see that they were doing a dictionary
attack on both passwords and account names. (I heard the server
writing logs constantly, and noticed sshd PIDs steadily increase,
so shut the door pretty soon.)

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

On 2008-05-15, Phil Carmody wrote:
> Ignoramus12901 writes:
>> On 2008-05-15, Phil Carmody wrote:
>>> Ignoramus12901 writes:
>>>> Do you know if there are any known exploit scripts written to exploit
>>>> this vulnerability?
>>>
>>> Given the amount of hammering my SSH ports are getting, I
>>> reckon that somebody has one!
>>
>> At least some of that hammering is due to old brute forcing dictionary
>> scripts.
>>
>> Ie login as root with passwords root, toor, r00t, t00r, root1, ... etc.
>
> Yup, on one briefly mis-configured machine, I was actually opening
> the port to them, and could see that they were doing a dictionary
> attack on both passwords and account names. (I heard the server
> writing logs constantly, and noticed sshd PIDs steadily increase,
> so shut the door pretty soon.)
>
> Phil

I have the ssh port open at all times.

I permit root logon only by authorized_keys, and several other logons
explicitly, but by default all other usernames are blocked.

--
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/