Should To and Cc header fields be protected?

[alejandro-colomar]

I believe this can be^W^Wis a security vulnerability, but it's so obvious that I don't think it should be embargoed.

Alice sends a secret message to Bob.
Mallory wants to read the message, and Bob's reply to it.

Mallory intercepts the message, and adds himself to the Cc: header field.
(I'm not sure if the following is possible, but let's assume it is:) Mallory also modifies the metadata of the encrypted part, to add himself as a listed recipient, even if he can't really decrypt the message. (@dd9jn, is this possible?)

Bob receives the message, and sees that Alice CCed Mallory, and that the encrypted message seems to be encrypted to Mallory too (currently, neomutt(1) doesn't show this, but Bob reads that info by running the gpg(1) command on the message; in the future, he sees that in the encryption information block).

When Bob replies to Alice, quoting a large part of the original message, he keeps Mallory in Cc (replies to all), disclosing the conversation to Mallory.

This could be prevented by protecting the To and Cc header fields, by including them in the signed part. It doesn't make sense to replace them by dummy ... as done with the Subject, since they need to receive the message, but it makes sense to repeat them in the signed part, and possibly warn if they don't match the outer ones (hmm, maybe we shouldn't warn if they mismatch; just showing the protected To and Cc in the pager should be enough; it's simpler).

[alejandro-colomar]

Related: #4221
Related: https://linux.codidact.com/posts/291205

[alejandro-colomar]

Related config:

     crypt_protected_headers_read
            Type: boolean
            Default: yes

            When set, NeoMutt will display protected headers  ("Memory
            Hole")  in  the pager, When set, NeoMutt will display pro‐
            tected headers in the pager, and will update the index and
            header cache with revised headers.

            Protected headers  are  stored  inside  the  encrypted  or
            signed  part of an an email, to prevent disclosure or tam‐
            pering.  For more information  see  https://github.com/au‐
            tocrypt/protected-headers  Currently NeoMutt only supports
            the Subject header.

            Encrypted messages using protected headers  often  substi‐
            tute  the  exposed  Subject header with a dummy value (see
            $crypt_protected_headers_subject).   NeoMutt  will  update
            its  concept  of  the correct subject after the message is
            opened, i.e. via the <display-message> function.   If  you
            reply  to a message before opening it, NeoMutt will end up
            using the dummy Subject header, so be sure to open such  a
            message first.  (Crypto only)

     crypt_protected_headers_subject
            Type: string
            Default: "..."

            When  $crypt_protected_headers_write  is set, and the mes‐
            sage is marked for encryption, this  will  be  substituted
            into the Subject field in the message headers.

            To  prevent  a  subject from being substituted, unset this
            variable, or set it to the empty string.  (Crypto only)

     crypt_protected_headers_write
            Type: boolean
            Default: no

            When set, NeoMutt  will  generate  protected  headers  for
            signed and encrypted emails.

            Protected  headers  are  stored  inside  the  encrypted or
            signed part of an an email, to prevent disclosure or  tam‐
            pering.   For  more information see https://github.com/au‐
            tocrypt/protected-headers

            Currently  NeoMutt  only  supports  the  Subject   header.
            (Crypto only)

[alejandro-colomar]

Alice sends a secret message to Bob. Mallory wants to read the message, and Bob's reply to it.

Mallory intercepts the message, and adds himself to the Cc: header field. (I'm not sure if the following is possible, but let's assume it is:) Mallory also modifies the metadata of the encrypted part, to add himself as a listed recipient, even if he can't really decrypt the message. (@dd9jn, is this possible?)

Bob receives the message, and sees that Alice CCed Mallory, and that the encrypted message seems to be encrypted to Mallory too (currently, neomutt(1) doesn't show this, but Bob reads that info by running the gpg(1) command on the message; in the future, he sees that in the encryption information block).

When Bob replies to Alice, quoting a large part of the original message, he keeps Mallory in Cc (replies to all), disclosing the conversation to Mallory.

The worst part of this bug is that Bob will assume that Alice CCed Mallory, and when Alice receives Bob's reply, Alice will also likely assume that Bob added Mallory to CC, so it's very likely that none of them would realize that Mallory added himself to the conversation maliciously.

[alejandro-colomar]

I think this deserves not only making To and Cc protected headers, but also change the default to protect headers. Not protecting headers is an insecure default, which is a bad thing, when dealing with crypto stuff. Consider users who may not know about the existence of this issue, or about the existence of the $crypt_protected_* options, and who will assume that enabling signing and encryption neomutt(1) will just do The Right Thing(tm).

[alejandro-colomar]

For messages without Cc, there should be an empty Cc: header field in the protected part, to avoid Mallory adding one outside of the protected part.

[alejandro-colomar]

Fun fact:

Old mutt(1) has a bug by which it injects To (and a few other header fields) into the protected header.

However, it's just a bug; probably they forgot to clear some structure.

It's clearly a bug, however, because mutt(1) never reads that back on the receiving side. It only presents the non-protected headers. So, a malicious actor can preserve the protected headers (so gpg(1) will accept the signature), modify the non-protected ones, and trick the recipient to trust the mail. Since mutt(1) doesn't show the protected To, the user cannot know about it.

[alejandro-colomar]

I think I'll end up protecting every AddressList in the Envelope structure.

[flatcap]

bcc leakage!

This isn't a bug in your changes, just a general feature of (Neo)Mutt.

Experimenting with both your PRs (#4221, #4227)...

I sent a signed/encrypted email to multiple recipients:

Compose

    From: Richard Russon <rich@flatcap.org>
      To: Alex Lacamoire <al@tangerine.com>
      Cc: Bing Crosby <bc@apple.com>
     Bcc: Cate Blanchett <cb@elderberry.com>
 Subject: Test

Security: Sign, Encrypt (PGP/MIME)
 Sign as: 0x69AD1D636AC292E820658C16EBC150E4B5DA63DF

Note, I have: set pgp_self_encrypt = yes

Email arrived (annotated with key owners)

Date: Fri, 5 Apr 2024 16:58:40 +0100
From: Richard Russon <rich@flatcap.org>
To: Alex Lacamoire <al@tangerine.com>
Cc: Bing Crosby <bc@apple.com>
Subject: ...
User-Agent: NeoMutt/20240329-149-6243fc

[-- Begin encryption information --]
Recipient: RSA key, ID 19D4D91AF95EE3D1 Alex Lacamoire <al@tangerine.com>
Recipient: RSA key, ID 934F123BFA86E1E9 Bing Crosby <bc@apple.com>
Recipient: RSA key, ID 7D276576DECDF4F8 Cate Blanchett <cb@elderberry.com>
Recipient: RSA key, ID 544F271C223CE792 Richard Russon (flatcap) <rich@flatcap.org>
[-- End encryption information --]

[-- The following data is PGP/MIME encrypted --]

[-- Begin signature information --]
Good signature from: Richard Russon (flatcap) <rich@flatcap.org>
            created: Fri 05 Apr 2024 16:58:40 BST
[-- End signature information --]

[-- The following data is signed --]

To: Alex Lacamoire <al@tangerine.com>
Cc: Bing Crosby <bc@apple.com>
Subject: Test

TEXT

NeoMutt effectively encrypts like gpg --recipient.
In the example above, the recipients can infer that Cate Blanchett was also sent a copy of the email.

Can we change the behaviour to mimic gpg --hidden-recipient for the bcc: field?

[alejandro-colomar]

bcc leakage!

This isn't a bug in your changes, just a general feature of (Neo)Mutt.

Hmmm!

Experimenting with both your PRs (#4221, #4227)...

I sent a signed/encrypted email to multiple recipients:

Compose

    From: Richard Russon <rich@flatcap.org>
      To: Alex Lacamoire <al@tangerine.com>
      Cc: Bing Crosby <bc@apple.com>
     Bcc: Cate Blanchett <cb@elderberry.com>
 Subject: Test

Security: Sign, Encrypt (PGP/MIME)
 Sign as: 0x69AD1D636AC292E820658C16EBC150E4B5DA63DF

Note, I have: set pgp_self_encrypt = yes

Email arrived (annotated with key owners)

Date: Fri, 5 Apr 2024 16:58:40 +0100
From: Richard Russon <rich@flatcap.org>
To: Alex Lacamoire <al@tangerine.com>
Cc: Bing Crosby <bc@apple.com>
Subject: ...
User-Agent: NeoMutt/20240329-149-6243fc

Seems good. The delivered message doesn't show the BCC.

[-- Begin encryption information --]
Recipient: RSA key, ID 19D4D91AF95EE3D1 Alex Lacamoire al@tangerine.com
Recipient: RSA key, ID 934F123BFA86E1E9 Bing Crosby bc@apple.com
Recipient: RSA key, ID 7D276576DECDF4F8 Cate Blanchett cb@elderberry.com
Recipient: RSA key, ID 544F271C223CE792 Richard Russon (flatcap) rich@flatcap.org
[-- End encryption information --]

Seems bad, but can be expected: we only encrypt once.

[-- The following data is PGP/MIME encrypted --]

[-- Begin signature information --]
Good signature from: Richard Russon (flatcap) rich@flatcap.org
created: Fri 05 Apr 2024 16:58:40 BST
[-- End signature information --]

[-- The following data is signed --]

To: Alex Lacamoire al@tangerine.com
Cc: Bing Crosby bc@apple.com
Subject: Test

TEXT

And seems good. The protected headers don't show the BCC. It's just the list of encryption recipients.

NeoMutt effectively encrypts like gpg --recipient. In the example above, the recipients can infer that Cate Blanchett was also sent a copy of the email.

Can we change the behaviour to mimic gpg --hidden-recipient for the bcc: field?

We could fix it in several ways:

• Encrypt only once, as we do, but ask gpg to hide the recipients that correspond to BCC. This would leave traces to the recipient that someone else can read it, possibly a BCC. It's not as bad of a leak, but it still leaks the fact that someone hidden got a copy. You could argue that it's a feature.

• Encrypt several times, so that each encrypted copy only shows the recipients that the recipient should see. Slower. Less leaky. But makes it easier to allow the sender to leak data without the recipient noticing (if they really want, they'll do it anyway).

The first one is what you suggest. At first glance, I agree, as I think it will be simpler to implement.

(I've copied the info from here into a new bug report.)