Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • evolution evolution
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 331
    • Issues 331
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • evolutionevolution
  • Issues
  • #299
Project 'GNOME/evolution-rss' was moved to 'Archive/evolution-rss'. Please update any links and bookmarks that may still have the old path.
Closed
Open
Issue created Jan 26, 2019 by Michał Górny@mgorny

Potential vulnerability: gpg key trust extrapolation to new UIDs

I'm not sure if this really counts as security vulnerability but I've marked it confidential just in case.

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 <alice@example.com>" [unknown]
gpg:                 aka "Eve <eve@example.com>" [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 <alice@example.com>
[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 <alice@example.com>), 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.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking