[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 May 2008 08:09:34 -0700
From: Kees Cook <kees@...ntu.com>
To: Robert Buchholz <rbu@...too.org>
Cc: oss-security@...ts.openwall.com
Subject: Re: OpenSSH key blacklisting
Hi,
On Sun, May 18, 2008 at 01:20:59AM +0200, Robert Buchholz wrote:
> On Saturday, 17. May 2008, Solar Designer wrote:
> > Besides the patch, it is equally important to agree on what keys to have
> > blacklisted, and to have the blacklist ready. I think we should have
> > "source" blacklists, which are per-{arch,key}-type and have 32 hex chars
> > per entry (no attempt at size reduction yet), so we'll be able to
> > (re)build the binary files from them.
> >
> > Right now, there doesn't appear to be a consensus on what key {type,
> > size} combinations to have in the blacklist yet. So let's discuss this.
>
> I like the Debian/Ubuntu idea of being able to add/remove blacklists
> easily. Personally, I generated an incomplete (due to lack of hardware)
> set of keys for RSA 1024, 2048, 4096, and DSA 1024 keys, since that is
> what I have seen in the wild.
> It might be argued that since Sep. 2006, few people generated 1024 bit RSA
> keys, but I do not know exactly when "ssh-keygen"'s default was changed.
>
> I'm putting Kees in CC since I hope he can help with the unshortened
> fingerprint list (at least via private mail).
Thanks for the CC. I'm on oss-security, but rather behind on all my
lists presently. ;)
The thought was to get DSA1024 and RSA2048 out asap because those were
the default settings through the vulnerable range of time. rsa2048 was
the ssh-keygen default the entire time, and if people still in the habit
of using "-t dsa" they'd get a dsa1024.
I just published full lists for rsa1024 to Debian[1], and I'm currently
waiting for rsa4096 to finish on be32 (it will be a few more days -- if
I have time today I'm going to hunt down a few other ppc boxes to help
out).
I'd like to get rsa8192 as well. I've seen dsa2048, but not in the
time-frame where it's an issue.
> > As to arch types, I've been told that Debian only supports le32, le64,
> > and be32 userlands, so we can safely omit be64.
That's correct. Same is true of Ubuntu.
> > The PID range can be 2 to 32767. PID 1 is init.
> > /proc/sys/kernel/pid_max defaults to 32768, but the highest PID value
> > specified in there is skipped, at least by current 2.6 kernels (we may
> > want to double-check this on older kernels). Of course, this does not
> > cover custom configs and patched kernels (e.g., some PID randomization
> > patch could alter the maximum PID value).
>
> Whoever changed his pid_max to another value, and generated the key after
> running some 33000 processes, would be both lucky (because his key is
> unlikeley to be in the attacker's keychain), and unlucky (since the key is
> not blacklisted). I see little point in supporting other than the default
> PIDs.
I had originally generated pid 0-32768 just because I had fired it off
quickly and was busy with other things. Rather than cleaning up the few
useless entries after the fact, I just threw them in with the others.
Now that things have settled down a little I plan to drop the hashes
for pid 0 and pid 32768. While pid 1 is insanely unlikely, I don't
want to rule out some kind of freaky embedded device that managed to do
keygen as pid 1. I lack imagination to think of a way it could happen,
but I'm not opposed to adding 1 extra hash per arch, per type/size.
-Kees
[1] http://packages.qa.debian.org/o/openssh-blacklist/news/20080517T222846Z.html
--
Kees Cook
Ubuntu Security Team
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
