Bug 973728 (CVE-2013-4166) - CVE-2013-4166 evolution: incorrect selection of recipient gpg public key for encrypted mail
Summary: CVE-2013-4166 evolution: incorrect selection of recipient gpg public key for ...
Alias: CVE-2013-4166
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 987108 990380
Blocks: 974906 988954
TreeView+ depends on / blocked
Reported: 2013-06-12 14:57 UTC by Yves-Alexis Perez
Modified: 2021-02-17 07:37 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-26 22:52:38 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:1540 0 normal SHIPPED_LIVE Low: evolution security, bug fix, and enhancement update 2013-11-21 00:40:51 UTC

Description Yves-Alexis Perez 2013-06-12 14:57:06 UTC
Description of problem:


this is actually not a RedHat/Fedora bug, it's an Evolution issue but the GNOME bugzilla doesn't seem to support reporting security/private bugs so Milan asked me to report here.

When selecting the key for GPG-encrypted mail, Evolution seems to do:

gpg --encrypt -r address

This is actually a bad idea, because it matches every userid including address (wether in the first or last name, in the comment or in the email address).

What makes it worse is that gpg returns the first match, so in case something else matches the email address given (for example name instead of first.name), then the mail will be encrypted to the *wrong* recipient. This looks like a security issue to me, thus marking it as such and reporting it. If you disagree, feel free to change that.

In the gpg manpage there's an explanation about how userid can be selected, and for example:

       By exact match on an email address.
              This is indicated by enclosing the email address  in  the  usual
              way with left and right angles.


So the angles should be added to the command line used by Evolution.

Note that this still won't work if multiple keys match that email address. Maybe Evolution should do the same as mutt, which seems to first search (using I guess gpg --list) the keys matching a query, then ask the user to select the uid. This would make sure the user actually knows to what recipient the mail is encrypted to.

And also note that, right now, there's no way to encrypt the mail to the correct recipient but to delete the key from the keyring.

Version-Release number of selected component (if applicable):

Evolution 3.8.2

How reproducible: Always

Steps to Reproduce:
1. create keys for multiple recipient with matching email addresses (test and foo-test)
2. try to write gpg encrypted mail to both addresses

Actual results:

Mail is always encrypted to the first matching user id.

Comment 1 Matthew Barnes 2013-07-20 17:20:15 UTC
I fixed the bracketing issue upstream in time for E-D-S 3.9.5 and 3.8.4:



The multiple match issue is something I'll be more willing to deal with once I port Camel to use GPGME instead of parsing raw gpg console output over pipes.

Comment 2 Yves-Alexis Perez 2013-07-20 18:38:24 UTC
Since this is now public per commit to the repository, I'll request a CVE from oss-sec.

Comment 3 Vincent Danen 2013-07-22 17:49:02 UTC
I'm going to turn this into an SRT bug so this can be properly tracked.

Comment 4 Vincent Danen 2013-07-22 17:50:48 UTC
CVE request:


Comment 5 Vincent Danen 2013-07-22 17:52:18 UTC
Do we know when this was introduced?  Or has Evolution since forever had this issue?

Comment 6 Vincent Danen 2013-07-22 18:00:29 UTC
Created evolution tracking bugs for this issue:

Affects: fedora-all [bug 987108]

Comment 7 Matthew Barnes 2013-07-22 20:49:46 UTC
(In reply to Vincent Danen from comment #5)
> Do we know when this was introduced?  Or has Evolution since forever had
> this issue?

It's present in the 1.5 releases from 2004.  That's as far back as I checked.  So effectively it's been there forever.

Comment 8 Vincent Danen 2013-07-26 19:00:28 UTC
This was assigned CVE-2013-4166 as per http://seclists.org/oss-sec/2013/q3/191

Comment 13 errata-xmlrpc 2013-11-21 04:52:50 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2013:1540 https://rhn.redhat.com/errata/RHSA-2013-1540.html

Comment 14 Vincent Danen 2015-02-26 22:52:38 UTC

Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Low security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.

Note You need to log in before you can comment on or make changes to this bug.