[Bug 393186] New: Detecting weak keys following the Debian OpenSSL desaster
https://bugzilla.novell.com/show_bug.cgi?id=393186 Summary: Detecting weak keys following the Debian OpenSSL desaster Product: openSUSE 10.3 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Security AssignedTo: security-team@suse.de ReportedBy: bugreports@tittel.net QAContact: qa@suse.de CC: benji@opensuse.org Found By: --- As probably nobody has missed, Debian got struck by a bug in their OpenSSL package, that lead to the generation of incredibly weak keys for SSH, SSL, OpenVPN etc.: http://www.debian.org/security/2008/dsa-1571 http://wiki.debian.org/SSLkeys As a consequence, a lot of weak SSL, SSH and OpenVPN keys are out there in the wild, which also poses a problem for users of openSUSE and SLED/SLES: 1) Weak SSL keys/certificates and SSH host keys created on Debian systems could be in use on SUSE systems and thus making encryption/authentication ineffective without the user noticing it (do you remember where and when you created every one of your SSH/SSL keys?). 2) SSH users of a SUSE system could have uploaded weak SSH public keys to their ~/.ssh/authorized_keys file, which poses a direct threat of unauthorized access to the SUSE machine. 3) Users of a SUSE system will connect to SSL-protected websites, mail servers etc., which use weak keys and not realize that their connection is not securely encrypted and also not secured from man-in-the-middle attacks. 4) Similar problems exist for other servies such as OpenVPN. The detection of weak keys is (to a certain degree) possible by comparing a public key with a list of known weak keys. See http://wiki.debian.org/SSLkeys#head-f2bdd99a686b944264c7ecd66a8361d64c15a656 and http://wiki.debian.org/SSLkeys#head-45e521140d6b8f2a0f96a115a5fc616c4f1baf0b. Debian already took some action to make at least OpenSSH complain if it hits known weak keys and provided tools to check the system for known weak keys. Of course it would be optimal if every software dealing with potentially affected keys would check if keys are weak, but that might not be practically feasible. However, some action should be taken for SUSE to at least prevent the worst and make SUSE users aware of that problem. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c1
--- Comment #1 from Marcus Meissner
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c2
--- Comment #2 from Marcus Meissner
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c3
--- Comment #3 from Marcus Meissner
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c4
--- Comment #4 from Marcus Meissner
I havent been following this debacle too closely as i dont have much to do with debian, however, wouldnt such a system be vulnerable to false positives if you are just going to hash partial fingerprints rather than whole fingerprints?
Such a system would have a higher likelihood of false positives, yes. However, it would not exactly be "vulnerable" to them - or at least, the worst-case impact (depending on server settings) is a DoS for a given user's ability to login. With 48-bit partial fingerprints, there may be like one such false positive in the entire world, or none. If we go down to 40 bits, it's less than one in a million of different keys. (I am assuming a blacklist size of around 200,000 partial fingerprints.) In fact, the Debian/Ubuntu patch already uses partial fingerprints based on my earlier suggestion, but I was more conservative at the time, so I suggested 80 bits. Willy Tarreau has since convinced me that even as low as 40 bits is reasonable. Oh, and we are not "hashing" fingerprints, we're merely matching them. Alexander -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c5
--- Comment #5 from Marcus Meissner
Are any other distros, besides Debian, Ubuntu, and derived ones, going to implement key blacklisting in OpenSSH - or are considering it?
We are considering it for Openwall GNU/*/Linux, and if our effort would be reused by others, or if others join us in developing and/or testing the patch, this would be a reason for us to go for it.
I don't think we'll take the Debian/Ubuntu patch as-is. Rather, we are likely to use a trivial binary encoding/compression method for the partial fingerprints. We'd also use smaller partial fingerprints. With the approach I have in mind, it'd take around 4.55 bytes per key to store 48-bit partial fingerprints, bringing the installed file size for 3 arch types and 2 key types/sizes in under 1 MB (or just over 1 MB for 3 key types/sizes).
We (Mandriva) have kinda sat back to see what other vendors are going to do. A few people have asked us to incorporate the Ubuntu patch, but the stance I've taken so far is that if upstream openssh is going to do it, then we will too. Otherwise I don't think we will, unless a number of other vendors are going to do so. We did send an announcement with more info to our security-announce mailing list to give our users a head's up, but didn't think we needed to push this on our users since very few will likely be affected. -- Vincent Danen @ http://linsec.ca/ -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c6
--- Comment #6 from Marcus Meissner
Are any other distros, besides Debian, Ubuntu, and derived ones, going to implement key blacklisting in OpenSSH - or are considering it?
We are considering it for Openwall GNU/*/Linux, and if our effort would be reused by others, or if others join us in developing and/or testing the patch, this would be a reason for us to go for it.
Gentoo is discussing the feature in bug #221759 [1]. Until now, I have not heard a reaction to the patch from our OpenSSH maintainers, so I cannot judge on the technical side of the inclusion.
I don't think we'll take the Debian/Ubuntu patch as-is. Rather, we are likely to use a trivial binary encoding/compression method for the partial fingerprints. We'd also use smaller partial fingerprints. With the approach I have in mind, it'd take around 4.55 bytes per key to store 48-bit partial fingerprints, bringing the installed file size for 3 arch types and 2 key types/sizes in under 1 MB (or just over 1 MB for 3 key types/sizes).
I assume whichever version has the acceptance of the OpenSSH upstream is what most of us would be willing to go with. Did you discuss either blacklist format with them already? Personally, I would like to see the feature ported to our distribution sooner than later, but neither at the cost of maintaining patchsets for the rest of existance, nor with high transition cost once upstream accepts another format. Robert [1] https://bugs.gentoo.org/show_bug.cgi?id=221759 [-- Ende der signierten Daten --] -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c7
--- Comment #7 from Marcus Meissner
Gentoo is discussing the feature in bug #221759 [1]. Until now, I have not heard a reaction to the patch from our OpenSSH maintainers, so I cannot judge on the technical side of the inclusion.
Thanks for the "bug" reference. FWIW, the shell script in this comment is vulnerable itself, in more than one way: http://bugs.gentoo.org/show_bug.cgi?id=221759#c9 For example, it lets a user have any other user's or root's authorized_keys removed, by replacing .ssh with a symlink to someone else's .ssh directory. It's just bad practice to access users' files as root (or as another user); this is difficult to do safely. Also, it misses authorized_keys2.
I assume whichever version has the acceptance of the OpenSSH upstream is what most of us would be willing to go with. Did you discuss either blacklist format with them already?
Yes, very briefly. They don't intend to implement key blacklisting. I suspect that a worm might change this, though. ;-)
Personally, I would like to see the feature ported to our distribution sooner than later, but neither at the cost of maintaining patchsets for the rest of existance, nor with high transition cost once upstream accepts another format.
Well, this is difficult to predict correctly. Alexander -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c8
--- Comment #8 from Marcus Meissner
Thanks for the "bug" reference. FWIW, the shell script in this comment is vulnerable itself, in more than one way:
http://bugs.gentoo.org/show_bug.cgi?id=221759#c9
For example, it lets a user have any other user's or root's authorized_keys removed, by replacing .ssh with a symlink to someone else's .ssh directory.
Do you mean the race condition between finding and removing the key? Otherwise, I cannot see how to have someone else's removed.
I assume whichever version has the acceptance of the OpenSSH upstream is what most of us would be willing to go with. Did you discuss either blacklist format with them already?
Yes, very briefly. They don't intend to implement key blacklisting.
That's not too helpful for our case. Do you have a patch to propose, implementing your idea? There has been approval of your idea inside Gentoo's hardened team. Robert [-- Ende der signierten Daten --] -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c9
--- Comment #9 from Marcus Meissner
On Friday 16 May 2008, Solar Designer wrote:
Thanks for the "bug" reference. FWIW, the shell script in this comment is vulnerable itself, in more than one way:
http://bugs.gentoo.org/show_bug.cgi?id=221759#c9
For example, it lets a user have any other user's or root's authorized_keys removed, by replacing .ssh with a symlink to someone else's .ssh directory.
Do you mean the race condition between finding and removing the key?
Yes, this is what I meant, but it is not the only issue - real or potential ("unverified", or depending on "unspecified" behavior, which I wouldn't want my servers' security to depend upon). Another real but minor issue is having this script rewind a backup tape or freeze up the machine (depends on what device files exist). It is just plain wrong to access users' files like that.
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, and this:
There has been approval of your idea inside Gentoo's hardened team.
is one of the reasons for us to go for the effort. We're not quite happy with the existing Debian/Ubuntu patch for other reasons as well, and doing a thorough security audit of that patch, then fixing whatever the audit uncovers could be about as time-consuming as coming up with a new patch. If other distros are interested, please speak up. 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. 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). Alexander -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c10
--- Comment #10 from Marcus Meissner
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 [-- Ende der signierten Daten --] -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c11
--- Comment #11 from Marcus Meissner
let's focus on the blacklist: .. I like the Debian/Ubuntu idea of being able to add/remove blacklists easily.
Just how easy do we want to make this? Do we need this capability for ourselves (package maintainers) or for end-users (sysadmins)? I'd choose the former, and use maybe Perl scripts for the task. Those scripts would be publicly available, such as via an URL posted to this mailing list, but not made a part of any packages. I find it undesirable to make this functionality directly available to end-users. That's for several reasons: 1. We'd have to spend far more time on the blacklist update code, perhaps programming it in C and making it extra-reliable (such as detecting incorrect invocations and input files), as well as on documentation for it. 2. Both pieces of code - the "updater" and the patch - would have to be made more generic (e.g., work for a wide range of blacklist sizes) - which might increase code size and complexity (e.g., we'd be tempted to support arbitrary "prefix lengths", not just 12 bits). 3. How would an end-user add a key to our blacklist? Would we have to support multiple blacklist files in the patch? Or would we include an "uncompressor" program? Or would the user need to download either the "source" blacklist or the "uncompressor" program? In the latter case, the user could as well download our "encoder" script, and not fear its dependency on Perl.
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.
What matters is when the default in Debian's package was changed, although it is possible that some users updated OpenSSL, but not OpenSSH, which would result in vulnerable 1024-bit RSA keys. Also, aren't protocol 1 keys 1024-bit RSA only, even with the latest ssh-keygen? Then, is it just one set of vulnerable 1024-bit RSA keys for both protocols - or is it two sets?
I'm putting Kees in CC since I hope he can help with the unshortened fingerprint list (at least via private mail).
I've dropped the explicit CC because Kees is subscribed. Kees - please let us know if you'd like to be CC'ed on most relevant postings. As to the fingerprint list, I'd appreciate it if you provide separate lists for different key types, sizes, and archs - such that we can produce any combinations. The "unshortened" aspect is not as important; we'll probably pick last N bits of fingerprints anyway, to allow for comparison between our blacklist and that in the Debian and Ubuntu packages.
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 agree. Thanks, Alexander -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c12
--- Comment #12 from Marcus Meissner
I've dropped the explicit CC because Kees is subscribed.
(I've adjusted my mail server to quit using SRS for the time being...)
postings. As to the fingerprint list, I'd appreciate it if you provide separate lists for different key types, sizes, and archs - such that we can produce any combinations. The "unshortened" aspect is not as important; we'll probably pick last N bits of fingerprints anyway, to allow for comparison between our blacklist and that in the Debian and Ubuntu packages.
Ah, I haven't been separating it by arch, but I can certainly do that. I've been including the "full" hashes in the Debian openssh-blacklist source package and reducing them for the final files. I can easily split up the source blacklist files by arch and combine them during the "build". I will probably also keep the file in PID order, and sort it during the build. I've been interested in the pid origin just to see where in the pid list keys tend to land. -Kees -- Kees Cook @outflux.net -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c13
--- Comment #13 from Marcus Meissner
Ah, I haven't been separating it by arch, but I can certainly do that. I've been including the "full" hashes in the Debian openssh-blacklist source package and reducing them for the final files. I can easily split up the source blacklist files by arch and combine them during the "build".
Yes, please split by {arch, key type, key size}. That is, let's have one "source" file per combination of these.
I will probably also keep the file in PID order, and sort it during the build.
Good idea. That way, it'd be easier for us to compare your blacklists against those others may have. What about my question re: RSA keys for protocol 1 vs. protocol 2? Thanks, Alexander -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c14
--- Comment #14 from Marcus Meissner
On Sun, May 18, 2008 at 09:12:16AM -0700, Kees Cook wrote:
Ah, I haven't been separating it by arch, but I can certainly do that. I've been including the "full" hashes in the Debian openssh-blacklist source package and reducing them for the final files. I can easily split up the source blacklist files by arch and combine them during the "build".
Yes, please split by {arch, key type, key size}. That is, let's have one "source" file per combination of these.
This has been done in the 0.2.1 upload of openssh-blacklist[1]. (I also dropped pid 0 and 32768, and sorted by pid, as mentioned earlier.) [1] http://packages.qa.debian.org/o/openssh-blacklist.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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c15
--- Comment #15 from Marcus Meissner
Also, aren't protocol 1 keys 1024-bit RSA only, even with the latest ssh-keygen?
Then, is it just one set of vulnerable 1024-bit RSA keys for both protocols - or is it two sets?
Yes -- in the tests I did, RSA1 and RSA keys shared the same modulus, so RSA1 is covered by the same blacklists. RSA1024 is in the openssh-blacklist-extra binary package in debian. As for other corner-cases, DSA2048 weren't generate-able[1] with a broken version of ssh-keygen, so I've been considering publishing an _empty_ DSA2048 blacklist, just so that ssh-vulnkey will report DSA2048 as "safe" instead of "unknown". -Kees [1] dsa was forced to be 1024 for a while now: $ ssh-keygen -f /tmp/foo -t dsa -b 2048 DSA keys must be 1024 bits -- Kees Cook @outflux.net -- 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.
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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c17
--- Comment #17 from Marcus Meissner
Not yet, but we (Openwall) are likely to have a patch within a few days, and this:
On Sat, May 17, 2008 at 04:46:30PM +0200, Robert Buchholz wrote:
There has been approval of your idea inside Gentoo's hardened team.
is one of the reasons for us to go for the effort.
Thank you. For tossing in an end-users view, it is also likely of wider interest since keys generated once may travel (floppy, USB stick, scp/rsync/ssh-add -L, you name it), or systems being cross-"updated" to other operating systems (into/out of Debian/Ubuntu) for instance, so it likely wouldn't hurt to forward the whole blacklisting or at least check tools upstream once everyone is happy with it. It may take some convincing upstream maintainers to help with working around a b0rkup issue that happend by a downstream distro, but anyways, I'd like to do some sort of "ssh-vulnkey -a" on my SUSE boxen (perhaps after some sanity checks such as making sure the file being read by this tool is actually a regular file after opening it and things like that). -- Matthias Andree -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c18
--- Comment #18 from Marcus Meissner
Hi,
Are any other distros, besides Debian, Ubuntu, and derived ones, going to implement key blacklisting in OpenSSH - or are considering it?
We are considering it for Openwall GNU/*/Linux, and if our effort would be reused by others, or if others join us in developing and/or testing the patch, this would be a reason for us to go for it.
I don't think we'll take the Debian/Ubuntu patch as-is. Rather, we are likely to use a trivial binary encoding/compression method for the partial fingerprints. We'd also use smaller partial fingerprints. With the approach I have in mind, it'd take around 4.55 bytes per key to store 48-bit partial fingerprints, bringing the installed file size for 3 arch types and 2 key types/sizes in under 1 MB (or just over 1 MB for 3 key types/sizes).
If this is going to be accepted as a more general solution, it'd be good to allow also for local, admin-maintened, blacklists, not just upstream maintened (and automatically updated). -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c19
--- Comment #19 from Marcus Meissner
If this is going to be accepted as a more general solution, it'd be good to allow also for local, admin-maintened, blacklists, not just upstream maintened (and automatically updated).
I agree that this might be desirable functionality, but unfortunately it has a price - we'd have to maintain two file parsers and lookup algorithms (perhaps binary and indexed, and text and sequential) or an additional program to update the binary file. (If we only create the binary file ourselves, then that program can be a quick hack - maybe even a Perl script.) Has there been any demand for such blacklists, prior to the Debian issue coming up? If not, then this additional feature is probably not worth implementing right away. Alexander -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c20
--- Comment #20 from Marcus Meissner
On Fri, May 16, 2008 at 05:10:43PM -0300, Gustavo De Nardin (spuk) wrote:
If this is going to be accepted as a more general solution, it'd be good to allow also for local, admin-maintened, blacklists, not just upstream maintened (and automatically updated).
I agree that this might be desirable functionality, but unfortunately it has a price - we'd have to maintain two file parsers and lookup algorithms (perhaps binary and indexed, and text and sequential) or an additional program to update the binary file. (If we only create the binary file ourselves, then that program can be a quick hack - maybe even a Perl script.)
Has there been any demand for such blacklists, prior to the Debian issue coming up? If not, then this additional feature is probably not worth implementing right away.
Not that I know of. I just imagined somewhere could have a policy like "all keys must have X bits" or ".. X or larger" X being a non-default size. So even if the database would be customized to have the extra keys, auto-upgrading it (which would be desirable) could be a problem. Not a big deal to me, personally. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c21
Marcus Meissner
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c22
--- Comment #22 from Marcus Meissner
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c33
--- Comment #33 from Marcus Meissner
Do you have a patch to propose, implementing your idea?
Dmitry V. Levin and I have completed design of the encoding scheme, and Dmitry implemented it. Now we have: blacklist-encode.c - the encoder program; blacklist-check.c - the "checker" program, used for testing only; openssh-3.6.1p2-owl-blacklist.diff - the patch to sshd. The patch is against an older version that we still have in Owl (with lots of other patches), but it is trivial to forward-port. In fact, I expect that Dmitry will port it to the newer version in ALT Linux's distributions very soon (if not already). Dmitry - please announce your forward-port in here when you have it. Dmitry has done fairly extensive testing, but we would not mind others in the community doing more tests and reporting back in here. We also have openssh-blacklist-0.3-1.bin.bz2, which is used as a "source" in our OpenSSH package. It was generated from ftp://ftp.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.3.tar.gz with: cat [DR]SA-{1024,2048}.[bl]e{32,64} | ./blacklist-encode 6 > openssh-blacklist-0.3-1.bin bzip2 !$ That is, it contains 48-bit partial fingerprints for 1024-bit and 2048-bit RSA and 1024-bit DSA keys for PID range 1 to 32767 (a total of almost 300k keys). The installed file size is just 1.3 MB, which corresponds to less than 4.5 bytes per fingerprint, and the .bz2 (and rpm) is just 1.2 MB. Lookups are very quick, and only three small portions of the file are read per lookup, for a total of under 100 bytes of data to read (as far as sshd is concerned). Neither the code nor the file format is specific to 48-bit partial fingerprints; it is possible to use larger ones by supplying something other than "6" (the size in bytes) on blacklist-encode's command-line. There is a safety check against even smaller values in blacklist-encode.c's main(), although if you really know what you're doing, you can go for 40-bit as well, bringing file size for the same keys to under 1 MB. Our latest source code may be found here: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/openssh/ (along with lots of other patches to OpenSSH). The pre-encoded blacklist file may be found here: ftp://ftp.ru.openwall.com/pub/Owl/pool/sources/openssh/ (and on other mirrors). I've attached current revisions of the source files and patch mentioned above. This is to encourage community review and comments, and to enable easy quoting of relevant context (please do not overquote). Please note that this effort was/is supported by CivicActions. It will enable us to receive funding for and get involved in more community activities in the future if you give due credit to both Openwall and CivicActions (especially with website links) when you reuse this stuff. Thanks in advance for any feedback. Alexander -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c34
--- Comment #34 from Marcus Meissner
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c35
--- Comment #35 from Marcus Meissner
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c36
--- Comment #36 from Marcus Meissner
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c37
--- Comment #37 from Marcus Meissner
On Sat, May 17, 2008 at 04:46:30PM +0200, Robert Buchholz wrote:
Do you have a patch to propose, implementing your idea?
Dmitry V. Levin and I have completed design of the encoding scheme, and Dmitry implemented it. Now we have:
blacklist-encode.c - the encoder program; blacklist-check.c - the "checker" program, used for testing only; openssh-3.6.1p2-owl-blacklist.diff - the patch to sshd.
The patch is against an older version that we still have in Owl (with lots of other patches), but it is trivial to forward-port. In fact, I expect that Dmitry will port it to the newer version in ALT Linux's distributions very soon (if not already). Dmitry - please announce your forward-port in here when you have it.
These changes for ALT Linux's openssh package can be found at http://git.altlinux.org/people/ldv/packages/?p=openssh.git It should apply to vanilla openssh-5.0p1 with trivial modifications to auth2-pubkey.c and servconf.c hunks. -- ldv -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c38
--- Comment #38 from Marcus Meissner
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c39
--- Comment #39 from Marcus Meissner
All,
Maybe I've missed something, in which case, shoot me down, but why unlike other services that make use of public key cryptography, does OpenSSH not have use a model which supports proper authorisation and revocation mechanisms? Would this not be an ideal opportunity to implement this? Whilst I think there was a reasonable case for such features prior to the Debian OpenSSL vulnerability being identified, I would argue that this issue highlights the case. Comercial SSH already has such functionality - can anyone offer a view on how [well] it works?
Tim -- Tim Brown mailto:timb@nth-dimension.org.uk http://www.nth-dimension.org.uk/
-- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c40
--- Comment #40 from Marcus Meissner
Last time I looked at the drafts (now RFC) there was no spec for revoking user-keys. However it allows x509 certificates for hostkeys. Its all about the RFCs. OpenSSH folks shouldnt implement proprietary stuff :)
AFAIK, SSH wasn't born of RFCs but rather the RFCs were born from an implementation. That being said, I don't consider an open source implementation (of a new standard) to be proprietry but rather a reference implementation which others can choose to follow (or not). Others may beg to differ. Moreover does the blacklist solution not count as a proprietry solution by the standards you suggest?
At the end of the day SSH is not really a PKI system. The focus has been on different issues.
True, but my argument is as to whether such focus is appropriate. On Wednesday 28 May 2008 15:43:39 Nathanael Hoyle wrote:
My first thought here has to do with the issues involved in key management. I'm not sure that a certifying/key-issuing central ($$$) authority with the ability to do revocations is the right model for most OSS users. Think SSL certificates and Verisign... I believe many OSS projects would not wish to incur this expense. Then you have self-signed certificates (and/or self-generated key pairs) and PGP/GPG-style web of trust things... all quite complicated and somewhat questionable.
The idea of CAs as a revenue generating model is IMO, something akin to snake oil. Certaily non-profit and private CAs exist and still provide value in certifying individuals and hosts. Why for example, could some way not be found to make it easier for host keys generated by a particular version/package of ssh-keygen to be revoked rather than employing the blacklist solution currently on the table. Moreover, why couldn't such a solution allow for alternative revocation source. In such a circumstance, the ssh client could be configured (at both a host and user level) to support both warning and/or preventing connections to hosts with revoked keys. *snip*
The specific case is somewhat unusual, because it is not an instance where a single host/site needed to revoke a previously valid key because of compromise (although that case is not properly addressed, currently), but one where many hosts, including those to which one has never before connected, might have keys which fall within the predictable space, and therefore be effectively compromised.
Exactly, and the blacklist solution fails to adequately address these use cases.
It is interesting to note that a typical 'web-of-trust' implementation would not properly handle this type of situation in a reliable manner, highlighting the need for a central key authority. The question then becomes, who in the OSS community would be considered a universally trusted entity to perform key registration and revocation for SSH key pairs, and how is such an entity funded?
Surely, the owner of the system and the owner of the client should both be able to make such choices by the configurations they apply to their systems.
Also, how does on resolve the apparent privacy concerns over querying such a central repository with a public key signature to check for revocation prior to usage? For my own purposes, I would not want to pass the key in question along... which means that perhaps an rsync-style source which could be synchronized to a local revoked key list is the proper implementation, avoiding disclosing which keys you were specifically interested in to the central key authority.
As I say, the owner of the system and the owner of the client should both be able to configure their own components. Therefore they would be in a position to make their own judgements on the trustworthiness or otherwise of a particular CA. Much as already happens with for example DNS blackholes for mail.
It's definitely a question worth pursuing, but I don't think it will be particularly trivial to solve across the community.
I don't doubt it, but if noone poses the question, we'll never find out if there is anyone smart enough to solve it. As such, I leave it for the reader to figure out if the problem has a solution. Tim -- Tim Brown mailto:tmb@65535.com -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c41
--- Comment #41 from Marcus Meissner
AFAIK, SSH wasn't born of RFCs but rather the RFCs were born from an implementation. That being said, I don't consider an open source One needs to dig in history but I think thats not quite true for SSH2. At least the SSH clients/servers today are written to implement the RFC.
implementation (of a new standard) to be proprietry but rather a reference implementation which others can choose to follow (or not). Others may beg to When I said "should not implement proprietary stuff" it was not meant that they are actually doing it today. Rather I acknowledged that it indeed meets the RFC quite well.
Blacklisting certain keys is probably not against the RFC, but it would be better to specify such additional security measurement in the RFC as well. Especially the point in time when it has to happen. I'd prefer blacklisting before the key is checked against the authorized_hosts file. (as it happens with the blacklist patch in SSH2 pubkey authentication) Sebastian -- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c42
--- Comment #42 from Marcus Meissner
Answering comments in line as applicable... Alright, doing same...
<snip>
On Wednesday 28 May 2008 15:43:39 Nathanael Hoyle wrote:
My first thought here has to do with the issues involved in key management. I'm not sure that a certifying/key-issuing central ($$$) authority with the ability to do revocations is the right model for most OSS users. Think SSL certificates and Verisign... I believe many OSS projects would not wish to incur this expense. Then you have self-signed certificates (and/or self-generated key pairs) and PGP/GPG-style web of trust things... all quite complicated and somewhat questionable.
The idea of CAs as a revenue generating model is IMO, something akin to snake oil.
To clarify, do you mean that the business model of commercial CAs is that of snake oil vendors, or that my statement, which implies that CAs necessarily be commercial is snake oil? I realize that not all CAs are commercial, but there are very few non-commercial ones which are well-recognized and whom could reasonably (IMO) be expected to have no interest/bias beyond ensuring that their key issuance product was solid. Certaily non-profit and private CAs exist and still provide value in
certifying individuals and hosts. Why for example, could some way not be found to make it easier for host keys generated by a particular version/package of ssh-keygen to be revoked rather than employing the blacklist solution currently on the table. Moreover, why couldn't such a solution allow for alternative revocation source.
A typical public key looks something like: id-rsa really-long-string-of-base64-encoded-key-here hostname Note that there is not a 'signature' from the version of ssh-keygen which created this key. I do not see any method of determining this information client-side when presented with a key upon connection. In the absence of this meta-information being available to the remote client, it cannot be used as the basis for revocation or acceptance. This is the sort of thing which could be addressed through an extension to the current RFC to mandate a comment or header field in both the keyfile and the client negotiation protocol which indicated the specific package and revision which generated the key. Obviously, in order for this to be useful, the RFC would have to mandate a standardized format for version strings so that they could be readily compared (i.e. versions <= X are known to be vulnerable). The concern introduced by such a mechanism is information disclosure. If I were acting the role of the script kiddie, a host becomes MUCH more interesting if it's client negotiation reveals that it's key-pair was generated using a known-vulnerable package revision. This could clue me in to the fact that a host had the reduced-keyspace issue like the recent debian one, or a similar one which would allow me to concentrate and focus my attack. That's bad news. It is probably sufficiently bad news as to bar adoption of such a mechanism. Note that putting a revision stamp in a keyfile could still allow an administrator to check hosts on his/her network to look for potentially compromised keys, without disclosing the information via the network protocol. Of course that means it is useless to the client. As to the second half of your question, about revocation source, I believe it makes good sense for the party which issued the ssh package and digitally signed it to be able to 'revoke' the package as insecure. For any other party to be authorized to do this, returns to the issue of a central CA. In such a circumstance,
the ssh client could be configured (at both a host and user level) to support both warning and/or preventing connections to hosts with revoked keys.
*snip*
The specific case is somewhat unusual, because it is not an instance where a single host/site needed to revoke a previously valid key because of compromise (although that case is not properly addressed, currently), but one where many hosts, including those to which one has never before connected, might have keys which fall within the predictable space, and therefore be effectively compromised.
Exactly, and the blacklist solution fails to adequately address these use cases.
In the general case, certainly. In the specific case, revoking each of the possibly generated keys from the reduced seed space does address the case-in-point issue.
It is interesting to note that a typical 'web-of-trust' implementation would not properly handle this type of situation in a reliable manner, highlighting the need for a central key authority. The question then becomes, who in the OSS community would be considered a universally trusted entity to perform key registration and revocation for SSH key pairs, and how is such an entity funded?
Surely, the owner of the system and the owner of the client should both be able to make such choices by the configurations they apply to their systems.
I wish that I could agree completely with you here, but I don't. In an 'ideal' world, absolutely. Probably those who are actively interested in auditing and maintaining the security of their systems could do so readily. That fact may be sufficient to drive the implementation of such an 'optional' extension. However, the reason debian got into the mess they did in the first place with this was specifically because they were trying to remove responsibility from the can't-be-bothered users for configuration. At one point, nearly all ssh key generation systems required the user the type keys 'at random' on the keyboard, and/or to move the mouse to generate an entropy pool for a seed value for key generation. Because debian performs key-generation on first boot in most cases, that early in the startup there might not be sufficient entropy in the network traffic for utility. I guess they found that users were either incapable of or disinclined to participate in the key generation process. These same users would not participate in configuring trusted certifying/revoking authorities for keypairs either. Thus the question becomes one of sufficiently acceptable default values for a distro vendor to pre-set. I am hard pressed to think of external non-commercial entities which could be entrusted with this task reliably enough that I would want to make them the default in a distro I packaged. I would welcome thoughts on that.
Also, how does on resolve the apparent privacy concerns over querying such a central repository with a public key signature to check for revocation prior to usage? For my own purposes, I would not want to pass the key in question along... which means that perhaps an rsync-style source which could be synchronized to a local revoked key list is the proper implementation, avoiding disclosing which keys you were specifically interested in to the central key authority.
As I say, the owner of the system and the owner of the client should both be able to configure their own components. Therefore they would be in a position to make their own judgements on the trustworthiness or otherwise of a particular CA. Much as already happens with for example DNS blackholes for mail.
The DNS blackholes for email is a very interesting case for comparison purposes. I find such to be indispensable for managing/controlling spam on an email network. As an implementation, this makes good sense. As per my above comments however, I fear that the benefits of such an implementation could be limited to the users who knew/cared and that this would not readily be pre-packageable for the masses.
It's definitely a question worth pursuing, but I don't think it will be particularly trivial to solve across the community.
I don't doubt it, but if noone poses the question, we'll never find out if there is anyone smart enough to solve it. As such, I leave it for the reader to figure out if the problem has a solution.
Agreed.
Tim
-Nathanael -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c43
--- Comment #43 from Marcus Meissner
All,
Maybe I've missed something, in which case, shoot me down, but why unlike other services that make use of public key cryptography, does OpenSSH not have use a model which supports proper authorisation and revocation mechanisms? Would this not be an ideal opportunity to implement this? Whilst I think there was a reasonable case for such features prior to the Debian OpenSSL vulnerability being identified, I would argue that this issue highlights the case. Comercial SSH already has such functionality - can anyone offer a view on how [well] it works?
Tim
My first thought here has to do with the issues involved in key management. I'm not sure that a certifying/key-issuing central ($$$) authority with the ability to do revocations is the right model for most OSS users. Think SSL certificates and Verisign... I believe many OSS projects would not wish to incur this expense. Then you have self-signed certificates (and/or self-generated key pairs) and PGP/GPG-style web of trust things... all quite complicated and somewhat questionable. Obviously, there has to be a way to invalidate a key. Doing it in a non-standardized way in the common implementation (openssh) isn't ideal. Using a 16-bit seed to generate a much longer key (the debian PID usage) is a great example of what happens when you try to automate/simplify certain things for the users (practically all distributions used to ask you to press letters on the keyboard and move the mouse to create an entropy pool...) in a way that invalidates the premise of the security model (a highly random seed value). The specific case is somewhat unusual, because it is not an instance where a single host/site needed to revoke a previously valid key because of compromise (although that case is not properly addressed, currently), but one where many hosts, including those to which one has never before connected, might have keys which fall within the predictable space, and therefore be effectively compromised. It is interesting to note that a typical 'web-of-trust' implementation would not properly handle this type of situation in a reliable manner, highlighting the need for a central key authority. The question then becomes, who in the OSS community would be considered a universally trusted entity to perform key registration and revocation for SSH key pairs, and how is such an entity funded? Also, how does on resolve the apparent privacy concerns over querying such a central repository with a public key signature to check for revocation prior to usage? For my own purposes, I would not want to pass the key in question along... which means that perhaps an rsync-style source which could be synchronized to a local revoked key list is the proper implementation, avoiding disclosing which keys you were specifically interested in to the central key authority. It's definitely a question worth pursuing, but I don't think it will be particularly trivial to solve across the community. -Nathanael -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c44
--- Comment #44 from Marcus Meissner
Maybe I've missed something, in which case, shoot me down, but why unlike other services that make use of public key cryptography, does OpenSSH not have use a model which supports proper authorisation and revocation mechanisms?
I haven't seen a working revocation mechanism implemented elsewhere. It's a very difficult problem. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c45
--- Comment #45 from Marcus Meissner
Thanks for the "bug" reference. FWIW, the shell script in this comment is vulnerable itself, in more than one way:
http://bugs.gentoo.org/show_bug.cgi?id=221759#c9
For example, it lets a user have any other user's or root's authorized_keys removed, by replacing .ssh with a symlink to someone else's .ssh directory. It's just bad practice to access users' files as root (or as another user); this is difficult to do safely.
Also, it misses authorized_keys2.
while the issues you raise are certainly valid in the general case, i wrote it for use on a constrained system -- users are not allowed login nor are they allowed to control any files directly. it's a gforge system, so all keys are managed via a web interface and the ssh backend is only for committing to svn/cvs/git repositories. so in this setup, none of the concerns you raise need to be accounted for. i leave it up to others to extend it for their own safe use ;). -mike -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=393186
User meissner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c46
--- Comment #46 from Marcus Meissner
https://bugzilla.novell.com/show_bug.cgi?id=393186
User anicka@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393186#c47
--- Comment #47 from Anna Bernathova
participants (1)
-
bugzilla_noreply＠novell.com