Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 May 2008 01:20:59 +0200
From: Robert Buchholz <>
Cc: Kees Cook <>
Subject: Re: OpenSSH key blacklisting

On Saturday, 17. May 2008, Solar Designer wrote:

> 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,


> 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 


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.