Bug 973728 - (CVE-2013-4166) CVE-2013-4166 evolution: incorrect selection of recipient gpg public key for encrypted mail
CVE-2013-4166 evolution: incorrect selection of recipient gpg public key for ...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20130722,reported=2...
: Security
Depends On: 987108 990380
Blocks: 974906 988954
  Show dependency treegraph
 
Reported: 2013-06-12 10:57 EDT by Yves-Alexis Perez
Modified: 2015-10-23 10:58 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-26 17:52:38 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yves-Alexis Perez 2013-06-12 10:57:06 EDT
Description of problem:

Hi,

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@example.com

This is actually a bad idea, because it matches every userid including address@example.com (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@example.com instead of first.name@example.com), 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.

         <heinrichh@uni-duesseldorf.de>

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@example.com and foo-test@example.com)
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 13:20:15 EDT
I fixed the bracketing issue upstream in time for E-D-S 3.9.5 and 3.8.4:

https://git.gnome.org/browse/evolution-data-server/commit/?id=5d8b92c622f6927b253762ff9310479dd3ac627d

https://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-8&id=f7059bb37dcce485d36d769142ec9515708d8ae5


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 14:38:24 EDT
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 13:49:02 EDT
I'm going to turn this into an SRT bug so this can be properly tracked.
Comment 4 Vincent Danen 2013-07-22 13:50:48 EDT
CVE request:

http://www.openwall.com/lists/oss-security/2013/07/21/2
Comment 5 Vincent Danen 2013-07-22 13:52:18 EDT
Do we know when this was introduced?  Or has Evolution since forever had this issue?
Comment 6 Vincent Danen 2013-07-22 14:00:29 EDT
Created evolution tracking bugs for this issue:

Affects: fedora-all [bug 987108]
Comment 7 Matthew Barnes 2013-07-22 16:49:46 EDT
(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 15:00:28 EDT
This was assigned CVE-2013-4166 as per http://seclists.org/oss-sec/2013/q3/191
Comment 13 errata-xmlrpc 2013-11-20 23:52:50 EST
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 17:52:38 EST
Statement:

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.