-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
anyone who has used hemlock to generate cryptographic keys (e.g. SSL certificates or SSH keys), or used keys generated elsewhere on hemlock, should be aware of this Debian security advisory:
http://lists.debian.org/debian-security-announce/2008/msg00152.html
such keys should be considered compromised, and replaced with newly generated keys. the version of OpenSSL currently installed on hemlock is not affected by this problem.
this does not affect keys generated or used on the stable server.
- river.
but surely, can't all the keys people are using for logging in been compromized?
On Tue, May 13, 2008 at 2:53 PM, River Tarnell river@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
anyone who has used hemlock to generate cryptographic keys (e.g. SSL certificates or SSH keys), or used keys generated elsewhere on hemlock, should be aware of this Debian security advisory:
http://lists.debian.org/debian-security-announce/2008/msg00152.html
such keys should be considered compromised, and replaced with newly generated keys. the version of OpenSSL currently installed on hemlock is not affected by this problem.
this does not affect keys generated or used on the stable server.
- river.-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFIKY9FIXd7fCuc5vIRAlugAKCFXJwNlKw+iLWwGo/5yQCHO43LcgCfV19J XpAR+TE9OFKv0TvF4a3yfdI= =cZ29 -----END PGP SIGNATURE-----
Toolserver-l mailing list Toolserver-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/toolserver-l
On Wed, May 14, 2008 at 8:00 PM, Carl Fürstenberg azatoth@gmail.com wrote:
but surely, can't all the keys people are using for logging in been compromized?
Indeed. Server admin log says a tool was run to check for vulnerable keys, and those users who had vulnerable keys were contacted personally by Brion.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Andrew Garrett:
Indeed. Server admin log says a tool was run to check for vulnerable keys, and those users who had vulnerable keys were contacted personally by Brion.
no, this was for the subversion server. Wikimedia admins don't touch the toolserver; no such tool has been run here.
- river.
River Tarnell wrote:
no, this was for the subversion server. Wikimedia admins don't touch the toolserver; no such tool has been run here.
- river.
Is it going to be? It might be worth the effort - surely giving insecure keys the ability to log into the server is far from ideal? Two or three of the keys which I'd generated recently and used as my authorized_keys on the toolserver were marked as "weak" by the tool - and I removed them from the file to avoid the risk... this should be done for users if not by them (with appropriate warning? motd?)..
*Using the script*:
wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz gzip -d dowkd.pl.gz perl dowkd.pl user your_username
Check for any "weak key" results.
I've copied dowkd.pl to /tmp on hemlock for those who'd rather copy it from there than download a 4MB file over and over again :).
Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Peeks:
I've copied dowkd.pl to /tmp on hemlock for those who'd rather copy it from there than download a 4MB file over and over again :).
i'll reply to the rest of this mail later, but for now i'll just point out that if you run random scripts from hemlock's /tmp, you're then trusting the security of your entire account to the person who put the script there.
i'd suggest that for important things like this, it should be downloaded from the original source.
- river.
River Tarnell wrote:
Martin Peeks:
I've copied dowkd.pl to /tmp on hemlock for those who'd rather copy it from there than download a 4MB file over and over again :).
i'll reply to the rest of this mail later, but for now i'll just point out that if you run random scripts from hemlock's /tmp, you're then trusting the security of your entire account to the person who put the script there.
i'd suggest that for important things like this, it should be downloaded from the original source.
I agree.
File duly removed from /tmp to encourage sensibility :)
Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Carl F?rstenberg:
but surely, can't all the keys people are using for logging in been compromized?
i'm not sure what you're asking here. as far as i understand the problem, using an SSH key to log into an affected server does not compromise the key. (if it did, that would be very bad, because the point of asymmetric cryptography is that the other end doesn't know your private key.)
the key _is_ affected if you copy the private part of the key to an affected server and use it there.
- river.
On Wed, May 14, 2008 at 12:08 PM, River Tarnell river@wikimedia.org wrote:
the key _is_ affected if you copy the private part of the key to an affected server and use it there.
But only if it was an DSA key. People who copied their RSA key to the toolserver should be safe (of course you need to ask yourself whether it is a good idea to put your keys on a shared system but that is another problem). If you did generate your RSA key on the toolserver you do have a problem.
Bryan
Bryan Tong Minh wrote:
But only if it was an DSA key. People who copied their RSA key to the toolserver should be safe (of course you need to ask yourself whether it is a good idea to put your keys on a shared system but that is another problem). If you did generate your RSA key on the toolserver you do have a problem.
Bryan
Interestingly when I ran the tool it marked some of my RSA keys (including my RSA host keys on my own boxes) as "weak", so if you use RSA, don't be complacent. Your keys could still be weak and you should check with the tool (see another post I made to this list).
Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Peeks:
Interestingly when I ran the tool it marked some of my RSA keys (including my RSA host keys on my own boxes) as "weak", so if you use RSA, don't be complacent. Your keys could still be weak and you should check with the tool (see another post I made to this list).
there are two different problems here:
1) any key (RSA or DSA) created with the affected OpenSSL version is insecure 2) any DSA private key used with the affected OpenSSL version could have been compromised
the tool only checks for case 1), because it can't possibly know where you've copied your key to and used it. so, there will be no difference for DSA vs RSA keys.
- river.
On Wed, May 14, 2008 at 6:08 AM, River Tarnell river@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Carl F?rstenberg:
but surely, can't all the keys people are using for logging in been compromized?
i'm not sure what you're asking here. as far as i understand the problem, using an SSH key to log into an affected server does not compromise the key. (if it did, that would be very bad, because the point of asymmetric cryptography is that the other end doesn't know your private key.)
the key _is_ affected if you copy the private part of the key to an affected server and use it there.
But the keys that some people use to log in may be compromised, if they were created on a vulnerable OpenSSL version not on the toolserver. Given that Brion disabled some people's commit keys, I take it that it's possible to tell whether a key is compromised just by examining the public key. Do you plan to do that, or allow people with compromised keys to continue to log in? Or is that a false dilemma?
On Wed, May 14, 2008 at 9:31 AM, Simetrical Simetrical+wikilist@gmail.com wrote:
But the keys that some people use to log in may be compromised, if they were created on a vulnerable OpenSSL version not on the toolserver. Given that Brion disabled some people's commit keys, I take it that it's possible to tell whether a key is compromised just by examining the public key. Do you plan to do that, or allow people with compromised keys to continue to log in? Or is that a false dilemma?
Yeah, this post was at least 40 minutes too late. Serves me right for reading my mail in chronological order. Never mind. :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Simetrical:
they were created on a vulnerable OpenSSL version not on the toolserver. Given that Brion disabled some people's commit keys, I take it that it's possible to tell whether a key is compromised just by examining the public key. Do you plan to do that, or allow people with compromised keys to continue to log in? Or is that a false dilemma?
as you can read in my previous mail to the list (a couple of minutes ago) affected keys have been disabled. however, not all broken keys can be detected automatically, just most of them.
- river.
toolserver-l@lists.wikimedia.org