Bug 676366 (CVE-2021-3349) – mail-client/evolution: gpg key trust extrapolation to new UIDs

• Product: Gentoo Security
• Status: CONFIRMED ---

[Description Michał Górny 2019-01-26 22:19:25 UTC]

I've reported this to GNOME GitLab.  Since it's confidential so far, I'm copying the description here.  I'll let you know once upstream decides what they think of it.


The way email signature checking is implemented in Evolution (and probably because of poor gpg --status-fd ... design), a signature can be reported as trusted with forged UID if another UID on the same key is marked as trusted.  Let me explain this a bit.

Let's say we have three people: Alice, Bob and Eve.  Originally, both Alice and Eve have their real identifiers on their key, and they both earn Bob's full trust (in terms of WoT).  Effectively, Bob's gpg will report both Alice's and Eve's signatures as trusted, with their appropriate UIDs.

Now, Eve adds to her key a new UID that forges Alice's UID.  Normally, this UID is reported by gpg as of 'unknown' trust which is correct.  If Eve makes a signature, gpg --verify indicates states of both UIDs:

gpg: Signature made sob, 26 sty 2019, 09:01:16 CET
gpg:                using RSA key EDA1165366204A694417B2FC551A87083FDCFBF0
gpg: Good signature from "Alice <[e-mail]>" [unknown]
gpg:                 aka "Eve <[e-mail]>" [full]

However, the --status-fd output doesn't really indicate that:

[GNUPG:] NEWSIG
[GNUPG:] KEY_CONSIDERED EDA1165366204A694417B2FC551A87083FDCFBF0 0
[GNUPG:] SIG_ID dbb5pG09OgJI0cRPGjqs2ZFAqyw 2019-01-26 1548489676
[GNUPG:] KEY_CONSIDERED EDA1165366204A694417B2FC551A87083FDCFBF0 0
[GNUPG:] GOODSIG 551A87083FDCFBF0 Alice <[e-mail]>
[GNUPG:] VALIDSIG EDA1165366204A694417B2FC551A87083FDCFBF0 2019-01-26 1548489676 0 4 0 1 8 01 EDA1165366204A694417B2FC551A87083FDCFBF0
[GNUPG:] KEY_CONSIDERED EDA1165366204A694417B2FC551A87083FDCFBF0 0
[GNUPG:] TRUST_FULLY 0 pgp
[GNUPG:] VERIFICATION_COMPLIANCE_MODE 23

Effectively, Evolution gets tricked into reporting a green 'Valid signature (Alice <[e-mail]>)', even though the Alice UID is not trusted.

---

To reproduce:

1. Make GNUPGHOMEs for Alice, Bob and Eve, and create new keys with unique UIDs for each of them.
2. Import Alice's and Eve's public keys to Bob.  Sign both of them.
3. Import signed Eve's public key back to Eve.
4. Use adduid on Eve's key to create a UID matching Alice's.
5. Create a new mail in mbox format signed using Eve's key.  Easy way: create a text file, --clearsign it, add mail headers.
6. Import the file as mbox into Evolution, and open the mail.

[Comment 1 Michał Górny 2019-01-28 14:39:26 UTC]

...and upstream closed the bug as 'gnupg doesn't let us do this easily'.  I've asked if they do mind opening it to the public then.

[Comment 2 Aaron Bauman (RETIRED) 2019-03-26 20:53:00 UTC]

(In reply to Michał Górny from comment #1)
> ...and upstream closed the bug as 'gnupg doesn't let us do this easily'. 
> I've asked if they do mind opening it to the public then.

Michał, not sure how you want to handle this. They are pointing to upstream GnuPG folks are the root of the problem.

[Comment 3 Michał Górny 2019-03-26 21:18:10 UTC]

I've already explained how this should be done (and done that based on upstream GnuPG folks response to a similar problem) -- they need to call 'gpg --with-colons --list-keys ...' and parse the output to get the trust of individual UIDs.

[Comment 4 Aaron Bauman (RETIRED) 2021-01-28 01:31:39 UTC]

For future reference as Gnome closed the bug.

https://dev.gnupg.org/T4735