Ubuntu/Debian vulnerability impact?
Ignoramus17861
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/
Adam W.
> In regards to this giant fuckup:
>
> http://www.ubuntu.com/usn/usn-612-2
You'll want to also look at
http://lists.debian.org/debian-security-announce/2008/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/13/debian_openssl_bug/
Ignoramus17861
> Feverishly pounding upon a keyboard Ignoramus17861 typed:
>> In regards to this giant fuckup:
>>
>> 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?
Joseph Ashwood
news:mcKdndL0Xr01PbfV...@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
phil-new...@ipal.net
| 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.
| 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) |
Man-wai Chang ToDie (33.6k)
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/
Ignoramus12901
> In comp.security.ssh Ignoramus17861 <ignoram...@nospam.17861.invalid> 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.
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.
Ignoramus12901
> "Ignoramus17861" <ignoram...@NOSPAM.17861.invalid> wrote in message
> news:mcKdndL0Xr01PbfV...@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?
Mark Wooding
> 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]
Ignoramus12901
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`:/
Mark Wooding
> Do you know if there are any known exploit scripts written to exploit
> this vulnerability?
I'm afraid I don't. Anyone else?
-- [mdw]
Moog
> 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.
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"
Ignoramus12901
> Ignoramus17861 illuminated alt.os.linux.ubuntu by typing:
>> 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.
>
> 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.
>
--
Moog
> On 2008-05-14, Moog <efc...@gmail.com> wrote:
>> Ignoramus17861 illuminated alt.os.linux.ubuntu by typing:
>>> 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.
>>
>> 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.
Ignoramus12901
> Ignoramus12901 illuminated alt.os.linux.ubuntu by typing:
>> On 2008-05-14, Moog <efc...@gmail.com> wrote:
>>> Ignoramus17861 illuminated alt.os.linux.ubuntu by typing:
>>>> 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.
>>>
>>> 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.
Phil Carmody
> 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
Ignoramus12901
> Ignoramus12901 <ignoram...@NOSPAM.12901.invalid> 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.
Phil Carmody
> On 2008-05-15, Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>> Ignoramus12901 <ignoram...@NOSPAM.12901.invalid> 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.)
Ignoramus12901
> Ignoramus12901 <ignoram...@NOSPAM.12901.invalid> writes:
>> On 2008-05-15, Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>>> Ignoramus12901 <ignoram...@NOSPAM.12901.invalid> 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.
Phil Carmody
> On 2008-05-15, Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>> Ignoramus12901 <ignoram...@NOSPAM.12901.invalid> writes:
>>> On 2008-05-15, Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>>>> Ignoramus12901 <ignoram...@NOSPAM.12901.invalid> 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.)
>
>
> I permit root logon only by authorized_keys, and several other logons
> explicitly, but by default all other usernames are blocked.
I permit ssh-ing in (using hosts.allow) only from a single
solaris box admin'ed by an old colleague, a NetBSD box admin'ed
by a BoFH and a half, and another Debian box admin'ed by a former
Debian project lead. So you either need to break both host_access
and ssh, or break into two separate boxes.
I've always been a login-as-luser, su/sudo for root access, kind
of guy.
Mark Madsen
> 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?
There is now a detailed examination online, see
http://metasploit.com/users/hdm/tools/debian-openssl/
I'm reading this in alt.os.linux.debian - where this has not been posted
AFAICT, so apologies to people in other groups who may have seen this
link already.
And to those of you in alt.os.linux.ubuntu, apologies for posting
something that does not contribute to your ongoing Windows/Ubuntu
flamewar....
dennis@home
"Mark Madsen" <mark.s.ma...@gmail.com> wrote in message
news:482c7a46$1...@news.bluewin.ch...
> And to those of you in alt.os.linux.ubuntu, apologies for posting
> something that does not contribute to your ongoing Windows/Ubuntu
> flamewar....
Thank you for that, some will use it as munitions, I will not worry now as
my keys were not done on debian system.
I have had a similar cock up in a random number generator I wrote once, not
a security issue though.
Its easy to do when you get programmers that understand the language more
than the algorithm they are programming or are just too tired when they do
the work. (hint: take a break if its important)
Ignoramus21037
> On Tue, 13 May 2008 21:27:48 -0500, 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)
>>
>> 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?
>
> There is now a detailed examination online, see
>
> http://metasploit.com/users/hdm/tools/debian-openssl/
>
> I'm reading this in alt.os.linux.debian - where this has not been posted
> AFAICT, so apologies to people in other groups who may have seen this
> link already.
The page is aweseome, just what I was hoping to find. Bookmarking...
> And to those of you in alt.os.linux.ubuntu, apologies for posting
> something that does not contribute to your ongoing Windows/Ubuntu
> flamewar....
--
Moog
> <snip>
> 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.
Obviously, weak phrases apart, however, all my systems have reported
back "Not Blacklisted" as opposed to "Compromised".
Moog
> <snip>
> And to those of you in alt.os.linux.ubuntu, apologies for posting
> something that does not contribute to your ongoing Windows/Ubuntu
> flamewar....
Only the people wanting to be in a flame war continue with it.
The rest simply amend their scorefile accordingly.
Ignoramus21037
> Ignoramus12901 illuminated alt.os.linux.ubuntu by typing:
>
>> <snip>
>> 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.
>
>
> Obviously, weak phrases apart, however, all my systems have reported
> back "Not Blacklisted" as opposed to "Compromised".
>
Great!
Did you upload any of your weak SSH keys to any other servers that are
not based on Debian? Did you check them also?
Moog
> On 2008-05-15, Moog <efc...@gmail.com> wrote:
>> Ignoramus12901 illuminated alt.os.linux.ubuntu by typing:
>>
>>> <snip>
>>> 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.
>>
>>
>> Obviously, weak phrases apart, however, all my systems have reported
>> back "Not Blacklisted" as opposed to "Compromised".
>>
>
> Great!
>
> Did you upload any of your weak SSH keys to any other servers that are
> not based on Debian? Did you check them also?
No none-debian servers. All checked. All come back OK.
Ignoramus21037
> Ignoramus21037 illuminated alt.os.linux.ubuntu by typing:
>> On 2008-05-15, Moog <efc...@gmail.com> wrote:
>>> Ignoramus12901 illuminated alt.os.linux.ubuntu by typing:
>>>
>>>> <snip>
>>>> 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.
>>>
>>>
>>> Obviously, weak phrases apart, however, all my systems have reported
>>> back "Not Blacklisted" as opposed to "Compromised".
>>>
>>
>> Great!
>>
>> Did you upload any of your weak SSH keys to any other servers that are
>> not based on Debian? Did you check them also?
>
> No none-debian servers. All checked. All come back OK.
>
Congrats. For me, it was about 8 of my privately owned computers and
about 6 computers at work with an extensive trust network. I hope that
I did not forget anything.
There is one more laptop left that is currently powered off.
Moog
> On 2008-05-15, Moog <efc...@gmail.com> wrote:
>> Ignoramus21037 illuminated alt.os.linux.ubuntu by typing:
>>> On 2008-05-15, Moog <efc...@gmail.com> wrote:
>>>> Ignoramus12901 illuminated alt.os.linux.ubuntu by typing:
>>>>
>>>>> <snip>
>>>>> 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.
>>>>
>>>>
>>>> Obviously, weak phrases apart, however, all my systems have reported
>>>> back "Not Blacklisted" as opposed to "Compromised".
>>>>
>>>
>>> Great!
>>>
>>> Did you upload any of your weak SSH keys to any other servers that are
>>> not based on Debian? Did you check them also?
>>
>> No none-debian servers. All checked. All come back OK.
>>
>
> Congrats. For me, it was about 8 of my privately owned computers and
> about 6 computers at work with an extensive trust network. I hope that
> I did not forget anything.
>
> There is one more laptop left that is currently powered off.
Good luck.
It's interesting that this security issue with ssh has caused so much
discussion.
Correct me if I'm wrong, but it was the Debian community that pointed
it out and the fix was almost instantaneous.
If only this sort of of diagnose/respond regime could be employed in
other walks of life.
Joe
> Only the people wanting to be in a flame war continue with it.
>
> The rest simply amend their scorefile accordingly.
>
<PLONK>
;-)
--
Joe - Linux User #449481/Ubuntu User #19733
joe at hits - buffalo dot com
"Hate is baggage, life is too short to go around pissed off all the
time..." - Danny, American History X
Trevor Best
> On 2008-05-15, Moog <efc...@gmail.com> wrote:
>
>> Only the people wanting to be in a flame war continue with it.
>>
>> The rest simply amend their scorefile accordingly.
>>
>
> <PLONK>
>
> ;-)
FS: Logitech keyboard, slight tea stain.
--
A lot of money is tainted: 'Taint yours, and 'taint mine.
dennis@home
"Moog" <efc...@gmail.com> wrote in message
news:slrng2pbne....@hardy.local...
> It's interesting that this security issue with ssh has caused so much
> discussion.
>
> Correct me if I'm wrong, but it was the Debian community that pointed
> it out and the fix was almost instantaneous.
>
> If only this sort of of diagnose/respond regime could be employed in
> other walks of life.
Moog, I notice in one of the other threads that quark and co are talking in
terms of root kits and stuff being inserted as a result of this flaw.
Is it very likely that some bad guys found the flaw in the two years it has
been present and used it?
I suppose they could find it fairly easy if they just diff important source
files and are looking for bugs like that.
I doubt if the community in general do such a thing so the bad guys could
have known about it for a while.
How do you check for unauthorised file changes on a Ubuntu system?
Is there a live CD with a checker on it?
Something that will compare what is in the packages with what is on the
system + something to check for malicious entries in the hosts, permissions,
etc.?
PS please ignore the rest who will come along in a bit and say this is a
troll, this could be very serious.
jellybean stonerfish
> ow do you check for unauthorised file changes on a Ubuntu system?
>
> Is there a live CD with a checker on it? Something that will compare
> what is in the packages with what is on the system + something to check
> for malicious entries in the hosts, permissions, etc.?
>
> PS please ignore the rest who will come along in a bit and say this is a
> troll, this could be very serious.
Exactly, but I wonder if I am just being paranoid. If there was a need
for a system scan, or reinstall, then they would have said so on the
debian security announcement. Right?
sf
Ignoramus620
How can they find out if you were compromised due to this bug?
You could have been.
Hard to know.
dennis@home
"jellybean stonerfish" <stone...@geocities.com> wrote in message
news:SogXj.3317$ah4...@flpi148.ffdc.sbc.com...
Its actually no different to any other security fix..
there is a period during which machines are vulnerable after the bug is
there and before it is fixed..
if someone finds the bug and uses it to exploit a machine, that machine is
compromised and needs to be fixed..
fixing it means checking for *any* exploit that could have been inserted.
The big problem here AFAICS is that it has been open for about two years and
its relatively easy for the bad guys to find.
(You can bet that the bad guys diff all the code changes looking for
vulnerabilities and will probably have found this one.)
This means that there are a huge number of machines that *may* have been
compromised and they all need checking.
Just closing the hole and ignoring the last two years is not a fix.
My advice, backup your data and reinstall, its probably quicker than doing
all the checks if they are not automated.
Then get the software writers to do a liveCD with a checker and run it
occasionally or at least after every set of fixes.
Moog
> On 2008-05-15, Moog <efc...@gmail.com> wrote:
>
>> Only the people wanting to be in a flame war continue with it.
>>
>> The rest simply amend their scorefile accordingly.
>>
>
><PLONK>
>
> ;-)
Heh.
Moog
>
>
> "Moog" <efc...@gmail.com> wrote in message
> news:slrng2pbne....@hardy.local...
>
>
>> It's interesting that this security issue with ssh has caused so much
>> discussion.
>>
>> Correct me if I'm wrong, but it was the Debian community that pointed
>> it out and the fix was almost instantaneous.
>>
>> If only this sort of of diagnose/respond regime could be employed in
>> other walks of life.
>
> Moog, I notice in one of the other threads that quark and co are talking in
> terms of root kits and stuff being inserted as a result of this flaw.
Well. I can only speak for myself here, but rkhunter runs as a cron
job on a regular basis on all my boxes.
I don't know what "other stuff" they refer to.....
Perhaps Apache related? I dunno. As I don't run any apache servers on
the machines I administer, or have inetd or xinetd enabled, then I'm
not sure how port 22 with keys that have been classed as "not
blacklisted" would actually allow anything in.
> Is it very likely that some bad guys found the flaw in the two years it has
> been present and used it?
I agree. It is a huge worry. Everyoe should check their systems. I
suggest if you've got a "compromised" key, you'd need to either
cleanse or re-install.
> I suppose they could find it fairly easy if they just diff important source
> files and are looking for bugs like that.
> I doubt if the community in general do such a thing so the bad guys could
> have known about it for a while.
>
> How do you check for unauthorised file changes on a Ubuntu system?
You deny root access via SSH. (or any other service that has an open
port)
> Is there a live CD with a checker on it?
> Something that will compare what is in the packages with what is on the
> system + something to check for malicious entries in the hosts, permissions,
> etc.?
I'm not aware of one. But I'm sure something like that will be in
existence.
> PS please ignore the rest who will come along in a bit and say this is a
> troll, this could be very serious.
Indeed. In fact, I edon't think anyone thinks you're trolling at all.
What I would say is that two people have done checks. Myself with no
problematic keys from 16. Ignoramus with 6 blacklisteds from 9.
Just on such a small number sampled, that gives a very high percentage.
Ross Younger
>> Do you know if there are any known exploit scripts written to exploit
>> this vulnerability?
* Mark Wooding <m...@distorted.org.uk> wrote:
>I'm afraid I don't. Anyone else?
There are a couple of interesting scripts, and the complete set of
vulnerable ssh keys for a selection of key sizes, linked from:
http://metasploit.com/users/hdm/tools/debian-openssl/
Ross
--
Ross Younger news#N...@crazyscot.com (if N fails, try N+1)
Darren Salt
[snip]
> What I would say is that two people have done checks. Myself with no
> problematic keys from 16. Ignoramus with 6 blacklisteds from 9.
I had one bad key of three used to access to remote systems. However, it was
locked down using the "from=" parameter in the relevant authorized_keys file.
I also had some bad sshd keys, but they don't matter since the sshds in
question aren't publicly accessible.
> Just on such a small number sampled, that gives a very high percentage.
100% on some systems, I shouldn't wonder.
Randomised key sizes (at generation time ‒ pick two ends of a range) would
seem to be useful to me, but I'm no cryptographer...
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING.
Mumble.