https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c16
--- Comment #16 from Marcus Meissner
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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.