oss-security - Re: OpenSSH key blacklisting

Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.