[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 May 2008 01:20:59 +0200
From: Robert Buchholz <rbu@...too.org>
To: oss-security@...ts.openwall.com
Cc: Kees Cook <kees@...ntu.com>
Subject: Re: OpenSSH key blacklisting
On Saturday, 17. May 2008, Solar Designer wrote:
<snip>
> It is just plain wrong to access users' files like that.
>
I won't judge the script any further, since personally I find one-time
checks unrealiable; let's focus on the blacklist:
> > Do you have a patch to propose, implementing your idea?
>
> Not yet, but we (Openwall) are likely to have a patch within a few days,
Great.
> 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).
> As to arch types, I've been told that Debian only supports le32, le64,
> and be32 userlands, so we can safely omit be64.
>
> 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.
Robert
Download attachment "signature.asc " of type "application/pgp-signature" (828 bytes)
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.
