oss-sec mailing list archives
Re: CVE Request: evolution mail client GPG key selection issue
From: Daniel Kahn Gillmor <dkg () fifthhorseman net>
Date: Thu, 25 Jul 2013 13:05:32 -0400
On 07/25/2013 04:46 AM, Kurt Seifried wrote:
Yeah this was discussed internally a bit at Red Hat after you filed the bug, it's a messy problem. I think one concern was where do you want to place policy decisions for key usage and trust, in GPG, in the app using it, or something else?
This is a critical observation. there currently exists a lot of infrastructure which uses gpg as the backend for dealing with keys. Moving those decision processes out of gpg and into frontends means that any tool which relies on gpg itself won't be able to make use of those policy decisions implemented only in a frontend.
One concern I have is I sometimes used to (not any more!) download all the signing keys for keys I was using to see if I could establish a web of trust.
Do you refresh your keyring regularly? If not, you risk not receiving notification of revocation and other updates. If you do refresh your keyring regularly, then you are also vulnerable to arbitrary user ID and subkey injection, since keys are fetched by keyid or fingerprint (including by subkey) and anyone can graft someone else's primary key to their own key as a subkey (even an expired one, or one without proper usage flags). In short: if anyone is relying on their local keyring as a "safe" storage place for keys they believe are valid, they're in an untenable position. GnuPG needs the user to explicitly indicate which keys are valid, and user agents which use GnuPG to encrypt messages need to only send to keys which are known to be validly bound (by a trusted certifier) to the User ID in question. This can be done by either (a) designating certain keys with strong enough "ownertrust" and then being willing to rely on their certifications, or by the user themselves certifying keys that they believe to be valid. If the user is the only trusted certifier, and they have a key that they are willing to use for a remote peer but they do not want to publish their certification, they can make a non-exportable certification (a.k.a. "local signature") to indicate to gpg that the peer's key is valid for their address.
Any ways for evolutions please use CVE-2013-4166 for this issue. Has anyone checked other popular mail clients like thunderbird/mutt/etc?
Thunderbird's enigmail plugin has a user preference (in the "advanced" pane of the expert preferences dialog, in the config editor as extensions.enigmail.hushMailSupport) that says "Use '<' and '>' to specify email addresses". The help text also mentions "disable if recipients have old hushmail keys" -- this defaults to being checked (the config option is "false" when the checkbox is checked, confusingly). So by default enigmail is "fixing" things in the same way as the proposed evolution fix, if i understand the bug report correctly. However, enigmail also has an option (under the "sending" pane of the hexpert preferences dialog, in the config editor as extensions.enigmail.alwaysTrustSend) which says "Always trust people's keys", with the help text of "Do not use the Web of Trust to determine the validaty of keys". this defaults to "true" (checked), which means that enigmail will happily send mail to a key that gpg does not believe belongs to the recipient address (i just tested this; it looks like with the default settings, enigmail will encrypt to the first key returned by gpg that has the given user ID, even if a later matching key has a higher validity). This is a separate issue from the User ID matching issue originally raised in this thread though. --dkg
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- CVE Request: evolution mail client GPG key selection issue Yves-Alexis Perez (Jul 21)
- Re: CVE Request: evolution mail client GPG key selection issue Kurt Seifried (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Yves-Alexis Perez (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Daniel Kahn Gillmor (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Kurt Seifried (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Daniel Kahn Gillmor (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Kurt Seifried (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Daniel Kahn Gillmor (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Kurt Seifried (Jul 25)