public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
* ssh keys and the Debian breach
@ 2008-05-14 23:06 Joe Buck
  2008-05-14 23:56 ` Joseph S. Myers
  2008-05-15  1:51 ` Joseph S. Myers
  0 siblings, 2 replies; 4+ messages in thread
From: Joe Buck @ 2008-05-14 23:06 UTC (permalink / raw)
  To: overseers

Hi all,

Have you guys done anything about possible bad keys for trusted
gcc/binutils/etc developers generated on Debian or Ubuntu boxes?

Apparently, for any given key length, Debian's openssh only generates
2^15 different keys, making exhaustive attacks possible.  See

http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html

While we're protected in various ways from tampering, we don't sign
snapshots, so a bad guy could tamper with a snapshot tarball and wait
until someone does "make install" as root.

There's a new ssh-vulnkey tool that identifies whether an ssh key
is one of the bad keys.

Please pardon me if you're all way ahead of me.  I worry. :-)

Joe

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ssh keys and the Debian breach
  2008-05-14 23:06 ssh keys and the Debian breach Joe Buck
@ 2008-05-14 23:56 ` Joseph S. Myers
  2008-05-15  1:51 ` Joseph S. Myers
  1 sibling, 0 replies; 4+ messages in thread
From: Joseph S. Myers @ 2008-05-14 23:56 UTC (permalink / raw)
  To: Joe Buck; +Cc: overseers

Someone with root needs to run the scanner (most of the authorized_keys 
files are world-readable, but not all, and only root can remove any 
insecure keys from them).

If updatekey appends to the file rather than replacing the contents, it's 
not an adequate solution for users to run updatekey, since the old key 
needs removing as well as a new secure one adding.

I don't know what differences there may be between the keys detected by 
ssh-vulnkey and those detected by the perl script linked from the original 
Debian advisory.

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ssh keys and the Debian breach
  2008-05-14 23:06 ssh keys and the Debian breach Joe Buck
  2008-05-14 23:56 ` Joseph S. Myers
@ 2008-05-15  1:51 ` Joseph S. Myers
  2008-05-15  5:01   ` Ian Lance Taylor
  1 sibling, 1 reply; 4+ messages in thread
From: Joseph S. Myers @ 2008-05-15  1:51 UTC (permalink / raw)
  To: Joe Buck; +Cc: overseers

See ~gccadmin/weak-key-list for a list of some keys that need disabling.  
This is non-exhaustive because it only includes world-readable keys, and 
there were lots of warnings from the script about keys it couldn't parse 
or didn't have a blacklist for their key length; ssh-vulnkey might well 
produce a different list.

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ssh keys and the Debian breach
  2008-05-15  1:51 ` Joseph S. Myers
@ 2008-05-15  5:01   ` Ian Lance Taylor
  0 siblings, 0 replies; 4+ messages in thread
From: Ian Lance Taylor @ 2008-05-15  5:01 UTC (permalink / raw)
  To: Joseph S. Myers; +Cc: Joe Buck, overseers

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> See ~gccadmin/weak-key-list for a list of some keys that need disabling.  
> This is non-exhaustive because it only includes world-readable keys, and 
> there were lots of warnings from the script about keys it couldn't parse 
> or didn't have a blacklist for their key length; ssh-vulnkey might well 
> produce a different list.

I have disabled those keys by adding a comment in the authorized_keys
file.  I also ran the scanner as root and disabled a few other keys.

Ian

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-05-15  3:57 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-05-14 23:06 ssh keys and the Debian breach Joe Buck
2008-05-14 23:56 ` Joseph S. Myers
2008-05-15  1:51 ` Joseph S. Myers
2008-05-15  5:01   ` Ian Lance Taylor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).