BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000
edit:
May 13th, @09:10AM
| Heads Up: Debian OpenSSL RNG Vuln CVE-2008-0166
http://lists.debian.org/debian-security-announce/2008/msg00152.html
quote:
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.
This is far reaching and potentially very bad. Key and certificate crypto relies on a good random number being used to work properly. This vulnerability means it's possible to guess all possible keys that have been generated using the affected versions of OpenSSL. Practically, this means crypto on these systems may be completely ineffective. Additionally, note that any key made with the library will carry the problem forward even if the libraries underneath have been corrected. So if you've run ssh-keygen, for example, you need to make new keys or even the updated system will still be vulnerable.
This is also going to affect Debian derived systems.
Edit: Added the bit about derivatives.
--
Overpower, overcome. |
|
Steve
Security is inefficient
Consultant
join:2001-03-10
Tustin, CA
edit:
May 13th, @10:11AM
| Actually, I think this is waffling on the use of the term "predictable", because in the random-number business it normally means that given one number produced by the RNG, one can compute, guess, or derive another number (the previous or the following number in the series).
When this is the case, it means that if I am on the system at the same time you're generating your SSH keys or SSL session, the random number I get will be computationally "close" to the random number you get, so I might be able to figure yours out.
My ability to exploit this vaporizes rapidly with the time difference between when I get my number and you get yours increases - it requires contemporaneous access to the same RNG.
But in the Debian case, it appears to be a much worse kind of predictable: it instead means that the RNG is pulling from a too-small pool of possible numbers, and though I might not be able to determine the next or prior number in the sequence, the pool of available numbers is small enough that I can attempt to brute-force the RNGs that produced it.
I have not studied the particular use of random numbers in SSL or SSH, but this looks yucky: if I know or suspect that your key came from a vulnerable Debian system, I can make a fair run as figuring out the key and can therefore decode your SSL session. And maybe even your SSH private key. I don't need to have access to your server to exploit it.
This really smells like bad news.
Edit - You could understand this problem as similar to taking a good, valid random number and using only the lower 16 bits instead of whatever the normal size is (though I doubt the actual bug is implemented this way).
Steve — who is not an expert on this area, and might be full of baloney |
|
BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000 | That's the attack as I understand it exactly. Thanks! |
|
deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE
 ·Verizon FIOS
 ·Comcast Workplace
 ·DSL EXTREME
| Thanks for the info.
Just stumbled upon this. Interesting point, not sure I entirely agree with it. But certainly in this case the author makes a good point. 
--
»hillaryis404.org/ |
|
Cabal
Premium
join:2007-01-21
02101
| quote:
Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it.
I know people hate to comment their code, but maybe intentionally using uninitialized memory would be a good opportunity for that sort of thing. 
--
Interested in open source engine management for your Subaru? |
|
Steve
Security is inefficient
Consultant
join:2001-03-10
Tustin, CA
| said by Cabal  :I know people hate to comment their code, but maybe intentionally using uninitialized memory would be a good opportunity for that sort of thing. Funny you should mention that |
|
evilghost
Premium
join:2003-11-22
Springville, AL
·Windstream
| reply to BeesTea
Is there any reason to regenerate the host-wide keys in /etc/ssh or just those created with ssh-keygen for use in authorized_keys?
|
|
BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000
| For sure host keys would be vulnerable too. The public/private key exchange to build an ssh session pre-auth is almost identical to the one used for auth.
It's going to be a while before all the impact of this is fully understood I think. Thanks for pointing that out. It might be worth brain dumping all the places where SSL might get used like that.
--
Overpower, overcome. |
|
refused
keeping IT real
join:2005-10-10
Redding, CA
| reply to evilghost
quote:
Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key
material for use in X.509 certificates and session keys used in SSL/TLS
connections. Keys generated with GnuPG or GNUTLS are not affected,
though.
if generated with 0.9.8c-1 or after, yah they should probably be regenerated with a fixed version. the security bulletin says the old stable version Sarge wasn't affected, so depends where your ssh keys came from and what version they came from. better safe than sorry though.
--
"Ubuntu" - an African word, meaning "Slackware is too hard for me". |
|
evilghost
Premium
join:2003-11-22
Springville, AL
·Windstream
edit:
May 13th, @09:35PM
| reply to BeesTea
I dissected the OpenSSH deb and this is the postinst script that runs to create the keys. Therefor, to recreate the host keys you can:
Dissected from postinst:
|
|
deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE
·Verizon FIOS
·Comcast Workplace
·DSL EXTREME
| That's going to make SO many ssh clients really, really unhappy
Necessary, obviously, but people are going to be seeing a lot of "man in the middle" type errors from ssh in the coming weeks.
--
»hillaryis404.org/ |
|
srgyhryt89yfn
@gov.br | reply to evilghost
Yes. You need to regenerate them, they're required for the security of the session setup. |
|
evilghost
Premium
join:2003-11-22
Springville, AL | reply to BeesTea
Glad I'm running 6.06 LTS so I don't have to deal with re-creating my Apache SSL cert, my Dovecot/Postfix .pem, and my SSH keys... |
|
EUS
Kill cancer
Premium
join:2002-09-10
Montreal, QC
clubs:  | reply to BeesTea
Ugh, ssh, apache2, postfix, vsftp, I have some cleaning up to do. |
|
deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE
·Verizon FIOS
·Comcast Workplace
·DSL EXTREME
| reply to BeesTea
I haven't tested it myself, but apparently this script can find affected keys:
»security.debian.org/project/extr···kd.pl.gz
It's a huge perl script, namely because it has the key data in the perl script itself.
Hope it's useful for some folks.
--
»hillaryis404.org/ |
|
Eatmeingreek
Gentard
join:2001-06-29
San Francisco, CA
| reply to BeesTea
Script seems to work. At least it identifies weak keys and they go away when you run evilghost 's commands.
Speaking of evilghost , the first line, "ssh-keygen -q -f /etc/ssh/ssh_host_key -N '' -t rsa1" creates files called "ssh_host_key" and "ssh_host_key.pub" that didn't already exist on all the Debian boxes I've tried so far. Don't think they're really needed.
Fortunately a lot of my Debian hosts started life as Sarge boxes so a lot have been unaffected so far.
--
"Be safe be suspicious" |
|
deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE | I don't think it (by default) supports RSA1 keys, and rightly so. They're quite insecure, relative to DSA and RSA2.
--
»hillaryis404.org/ |
|
djrobx
join:2000-05-31
Valencia, CA | reply to deblin
Script appears to work. Tried it against a Sarge-generated host keys and it was quiet. Tried it against a recently installed Etch server and it reported the weak keys. After upgrading and regenerating the host keys, it was quiet. |
|
BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000 | Excellent feedback. Thanks!
--
Overpower, overcome. |
|
evilghost
Premium
join:2003-11-22
Springville, AL
·Windstream
| reply to Eatmeingreek
said by Eatmeingreek :Script seems to work. At least it identifies weak keys and they go away when you run evilghost 's commands. Speaking of evilghost , the first line, "ssh-keygen -q -f /etc/ssh/ssh_host_key -N '' -t rsa1" creates files called "ssh_host_key" and "ssh_host_key.pub" that didn't already exist on all the Debian boxes I've tried so far. Don't think they're really needed. Fortunately a lot of my Debian hosts started life as Sarge boxes so a lot have been unaffected so far. Agree, rsa1 not needed, at least on this end. Edited my post, thanks for pointing this out. |
|
