[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51F15ADC.8080109@fifthhorseman.net>
Date: Thu, 25 Jul 2013 13:05:32 -0400
From: Daniel Kahn Gillmor <dkg@...thhorseman.net>
To: oss-security@...ts.openwall.com
CC: Kurt Seifried <kseifried@...hat.com>,
Yves-Alexis Perez <corsac@...ian.org>
Subject: Re: CVE Request: evolution mail client GPG key selection
issue
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
Download attachment "signature.asc" of type "application/pgp-signature" (1028 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.
