Message security; protected header fields

[Alejandro Colomar]

Hi mutt(1) and neomutt(1) developers!

I reported around a month ago a couple of security vulnerabilities to
neomutt(1), but which are also present in mutt(1) and every MUA
(probably, I didn't do an exhaustive research).

Vulnerability reports:

-  
-  

I also sent a report to Debian and Red Hat security teams to issue a
couple of CVEs.  I haven't received a response from the security teams,
but I guess they're busy at the moment with xz.

Richard and a few other neomutt(1) developers have helped me discuss
and polish these features.

We created a page to discuss the security of messages, and have an
overview of how to address these issues, and a few smaller ones.

-  

This PR addresses both security vulnerabilities:

-  

There are other spin-offs of that discussion, including the following
issues and PRs:

-  
   (this was a debugging feature that led me to this rabbit hole)

-  
-  
-  

-  

-  

-  

-  
-  

-  

Although it's a draft, since I have written alternative patches in other
PRs.  All the details are in the discussion page.

You're all invited to discuss this thing before we merge the changes.
I'd love if mutt(1) would be interested in coordinating the patches,
since I'm myself a mutt(1) user.  I just started developing them for
neomutt(1) because it's more open to development.  If you are open to
(some of) these changes, I could adapt the patches for mutt(1) too.

Here's an overview of my initial idea, using ASCII art.  Please scroll
to the right of the screen to see it all.  I've removed some bits that
I've discarded.

Date: Sat, 30 Mar 2024 12:22:13 +0100
From: Alejandro Colomar*10
Reply-To: e...@example.com*10
To: a...@kernel.es
Cc: b...@example.com   *10
Subject: ...

[-- Begin encryption information --]  \
Recipient: RSA key, ID 1234123412341234   |
Recipient: RSA key, ID 5678567856785678   }-- Hide: 
$crypt_encryption_info = no
Recipient: RSA key, ID    *7  |
[-- End encryption information --]/

[-- Begin signature information --]
Good signature from: Alejandro Colomar 
aka: Alejandro Colomar 
aka: Alejandro Colomar Andres 
created: Sat Mar 30 12:22:13 2024
[-- End signature information --]

[-- Warning: the header field 'Reply-To' has been tampered with --]  *11
[-- Warning: the header field 'Sender' has been tampered with --]
[-- Warning: the header field 'Mail-Followup-To' has been tampered with --]
[-- Warning: the header field 'X-Original-To has been tampered with --]
[-- Warning: the header field 'To' has been tampered with --]
[-- Warning: the header field 'In-Reply-To' has been tampered with --]

[-- The following data is PGP/MIME signed and encrypted --]   *3
From: Alejandro Colomar*8  \ \
Sender: f...@foo.com   | |
Reply-to: f...@foo.com }-|-{- Weed: 
weed && _protected_headers_weed = yes
Mail-Followup-To: f...@foo.com | |  \- 
Don't send: $crypt_protected_headers_write = no
X-Original-To: f...@foo.com| |
To: f...@foo.com   | |
Cc: b...@example.com   | }-- Hide: 
$crypt_protected_headers_read = no
Subject: Foo  | |
In-Reply-To: <...>*9  / |
  *4/
Body body
body body body
body
[-- End of PGP/MIME signed and encrypted data --] *3


*3:   No gratuituous blanks after the begining or before the ending
  [-- ... --] markers.

*4:   Blank line is part of this block. This one is meaningful, and
  should be printed if the header area is printed; even if the
  header area has 0 fields!

*6:   We should default to protecting these fields in outbound email.
  Not doing so is a security risk with no benefits (other than maybe
  repudiating one's own signed mail).

*7:   BCCs should be 

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote:
>g. Protecting the recipients is problematic for potentially several
>   reasons--it prevents people from interacting normally with
>   threads and their recipients.  The SMTP envelope needs at least
>   the recipient you're actually sending to in that specific SMTP
>   session, and the MTA will add the recipient's address in a
>   Received header, so hiding that at least is pointless.  But if
>   Mutt added these features it would be the only client to do so
>   (AFAIK) making it very difficult for anyone using any other
>   client to deal with.  You couldn't simply "reply-all" to, well,
>   reply to all...  And again, you can just send separate messages.
>   And if you really don't want your recipients to know about each
>   other, then you shouldn't be sending them the same message
>   anyway!  Avoid any possibility of embarrassment or worse--send
>   separate messages.

I don't think you've understood the issue at all.

Protecting the recipients and the in-reply-to doesn't mean hiding it.
It means providing a copy inside the signed part, so that it can be
verified against tampering.  It's not about encrypting them.

So, if I manage you to send me a message saying "Yeah, go ahead.", and
I change the recipient and in-reply-to header fields, I could maybe
convince someone that you said yes to a different thread.  Does that
not look like a security problem to you?  Well, that's fine.

BTW, mutt(1) is already incompatible with e.g. thunderbird(1) regarding
the Subject.  That's precisely why I wanted some agreement on this
outside of just neomutt(1).

> 2. Many of these violate existing standards, or at least have no
>standard.  Standards exist for a reason--if you don't follow them,
>other people who don't happen to use the exact same client as you
>won't be able to interoperate.

I don't think so.  Again, I don't think you've understood the points.

> 3. Probably most importantly, Mutt is basically in maintenance mode,
>i.e. no new features.  So none of this is likely to get
>implemented, even if one of the developers happened to agree with
>you.

I was just suggesting.  If you don't like it, then it's fine.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 19, 2024 at 01:59:57AM +0200, Alejandro Colomar wrote:
> BTW, now that I remember, while developing these things for neomutt(1),
> I found that mutt(1) has a bug (?) by which it does actually protect
> some header fields precisely in the way that I implemented them in
> neomutt(1), with the difference that mutt(1) does it on accident.

I don't know whether or not it's intentional, but it does seem to be a
bug to me...  The message headers do not belong in the MIME headers
section.  But also note that Mutt doesn't do anything with them,
including display them (at least not here).

>   $ mutt -v | head -n1
>   Mutt 2.2.12+68 (841caf1c) (2023-10-25)

Yeah, mine is a bit older. =8^)


-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Thu, Apr 18, 2024 at 06:37:50PM +0200, Alejandro Colomar wrote:
> Hi mutt(1) and neomutt(1) developers!
> 
> I reported around a month ago a couple of security vulnerabilities to
> neomutt(1), but which are also present in mutt(1) and every MUA
> (probably, I didn't do an exhaustive research).

While I don't presume to speak for Kevin, or anyone with commit
access, here are my thoughts:

1. None of the issues you listed are security vulnerabilities.  I'm
   also fairly sure that anyone sophisticated enough to use Mutt AND
   make regular use of encryption is not going to be confused by any
   of the display-related issues you pointed out.  If you are going to
   use encryption, then it's incumbent upon you, the user, to
   understand how it works, what it protects, and what it does not
   protect.  It's definitely an advanced use case.
   
   a. If you don't want to expose the "real" subject--don't.  You have
  full control over what you put there.  Likewise, you can also
  write whatever you want in the body of the message to address
  that.

   b. There are valid reasons (e.g. Bcc) why the message may be
  encrypted to someone not on (your copy of) the headers.  By and
  large, as the recipient, that's none of your business.
  Presumably, the sender knows what's happening and that's what
  matters.

   c. Pretty much the same thing with a listed recipient to whom the
  message is NOT encrypted.

   d. The blank lines are for readability--a display-only concern--and
  displaying them has no actual impact on security.  If you have
  reason to do something with the actual encrypted body other than
  neatly displaying it for your reading pleasure, process the
  actual message body outside Mutt in whatever manner you care to.

   e. "Hidden" recipients:  If you want to hide your recipients from
  each other, just send a separate message.  I haven't ever needed
  to but presumably you can use Mutt's command line interface to
  script this, so it's probably actually pretty trivial to do that
  already.

   f. "phishing protection" -- First, in the context of encrypted
  messages, this doesn't seem like a legitimate concern.  You're
  going to know who your recipients are, and their keys, and this
  won't be a factor.  But recipients' (or senders') addresses
  which are not 8-bit clean need to be encoded anyway, according
  to RFC 6531, so just looking at the headers will already reveal
  that.

   g. Protecting the recipients is problematic for potentially several
  reasons--it prevents people from interacting normally with
  threads and their recipients.  The SMTP envelope needs at least
  the recipient you're actually sending to in that specific SMTP
  session, and the MTA will add the recipient's address in a
  Received header, so hiding that at least is pointless.  But if
  Mutt added these features it would be the only client to do so
  (AFAIK) making it very difficult for anyone using any other
  client to deal with.  You couldn't simply "reply-all" to, well,
  reply to all...  And again, you can just send separate messages.
  And if you really don't want your recipients to know about each
  other, then you shouldn't be sending them the same message
  anyway!  Avoid any possibility of embarrassment or worse--send
  separate messages.

   h. The rest are just minor display issues--preferences--and have
  nothing to do with security whatsoever AFAICT.

2. Many of these violate existing standards, or at least have no
   standard.  Standards exist for a reason--if you don't follow them,
   other people who don't happen to use the exact same client as you
   won't be able to interoperate.

3. Probably most importantly, Mutt is basically in maintenance mode,
   i.e. no new features.  So none of this is likely to get
   implemented, even if one of the developers happened to agree with
   you.
   
Personally, I would not be in support of the vast majority of what you
suggested.  Maybe the "hidden recipient" for Bcc, but again, avoid the
whole problem and send a separate message.  But the bulk of what
you're suggesting is a ton of work and extra complexity for really
very little or no genuine benefit, and potentially significant
interoperability problems.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Thu, Apr 18, 2024 at 11:59:29PM +0200, Alejandro Colomar wrote:
> Protecting the recipients and the in-reply-to doesn't mean hiding it.
> It means providing a copy inside the signed part, so that it can be
> verified against tampering.  It's not about encrypting them.

You can already do this in mutt by using a script as your editor to
parse the headers, add the info you want to the body, and then edit
your message.  But it doesn't really guarantee what you want because
as I already pointed out, the message headers may differ from the
actual recipients for a variety of reasons (Bcc, forwarding, mailing
lists, etc.).  It may indicate a difference--it does not guarantee
that the difference is caused by tampering.  It most likely is not, so
it will most likely mislead you.

The message interception scenario is possible, but I think highly
improbable, especially for the sort of people who are using Mutt and
encryption--savvy users.  It requires the attacker have superuser
access to the mail system somewhere between you and your genuine
recipients, AND either be known to your recipients, or your recipients
must have no idea who should be on the message.  The attacker needs to
be able to prevent the delivery of the original, to have time to
inject the bogus message.  And your recipients need to already have
the attacker's public key and trust it, or be set up to automatically
download and use untrusted public keys...  

> BTW, mutt(1) is already incompatible with e.g. thunderbird(1) regarding
> the Subject.  That's precisely why I wanted some agreement on this
> outside of just neomutt(1).

How so?

> > 2. Many of these violate existing standards, or at least have no
> >standard.  Standards exist for a reason--if you don't follow them,
> >other people who don't happen to use the exact same client as you
> >won't be able to interoperate.
> 
> I don't think so.  Again, I don't think you've understood the points.

For instance, if you rely on the in-body headers when they differ from
the message headers, the other recipients' response behavior will
differ from yours, because that is not how e-mail works.  The
standards dictate that e.g. the reply-to header--not some random text in
the message body--is the address that e-mail clients should send
replies to.  So yes, it violates the spec.

> Have a lovely night!

You too!

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Kurt Hackenberg]

On Thu, Apr 18, 2024 at 06:37:50PM +0200, Alejandro Colomar wrote:


I reported around a month ago a couple of security vulnerabilities to
neomutt(1), but which are also present in mutt(1) and every MUA


So the main security vulnerability is that a recipient can tamper with 
header fields, and then reuse the message in some way, perhaps resend 
it?  And you propose to cryptographically sign certain headers to 
detect tampering?


Signing header fields sounds reasonable, but I don't entirely like an 
implementation that puts a copy of them in the message body, to be 
covered by GPG.  I'd prefer something more direct, that signs headers 
without copying them or modifying the message body.


DKIM already exists, and signs header fields.  It publishes a key 
through DNS, and so is used by the administrator of the sending domain 
rather than by the end user.  Is that acceptable?


Email authentication: 

DKIM: 

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 18, 2024 at 11:59:29PM GMT, Alejandro Colomar wrote:
> Hi Derek,
> 
> On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote:
> >g. Protecting the recipients is problematic for potentially several
> >   reasons--it prevents people from interacting normally with
> >   threads and their recipients.  The SMTP envelope needs at least
> >   the recipient you're actually sending to in that specific SMTP
> >   session, and the MTA will add the recipient's address in a
> >   Received header, so hiding that at least is pointless.  But if
> >   Mutt added these features it would be the only client to do so
> >   (AFAIK) making it very difficult for anyone using any other
> >   client to deal with.  You couldn't simply "reply-all" to, well,
> >   reply to all...  And again, you can just send separate messages.
> >   And if you really don't want your recipients to know about each
> >   other, then you shouldn't be sending them the same message
> >   anyway!  Avoid any possibility of embarrassment or worse--send
> >   separate messages.
> 
> I don't think you've understood the issue at all.
> 
> Protecting the recipients and the in-reply-to doesn't mean hiding it.
> It means providing a copy inside the signed part, so that it can be
> verified against tampering.  It's not about encrypting them.
> 
> So, if I manage you to send me a message saying "Yeah, go ahead.", and
> I change the recipient and in-reply-to header fields, I could maybe
> convince someone that you said yes to a different thread.  Does that
> not look like a security problem to you?  Well, that's fine.
> 
> BTW, mutt(1) is already incompatible with e.g. thunderbird(1) regarding
> the Subject.  That's precisely why I wanted some agreement on this
> outside of just neomutt(1).
> 
> > 2. Many of these violate existing standards, or at least have no
> >standard.  Standards exist for a reason--if you don't follow them,
> >other people who don't happen to use the exact same client as you
> >won't be able to interoperate.
> 
> I don't think so.  Again, I don't think you've understood the points.

BTW, now that I remember, while developing these things for neomutt(1),
I found that mutt(1) has a bug (?) by which it does actually protect
some header fields precisely in the way that I implemented them in
neomutt(1), with the difference that mutt(1) does it on accident.

I use

$ mutt -v | head -n1
Mutt 2.2.12+68 (841caf1c) (2023-10-25)

See the reply that I sent you in the list archives, which I sent with
mutt(1), and you'll find the protected headers
:

From mutt-dev  Thu Apr 18 21:59:29 2024
From: Alejandro Colomar 
Date: Thu, 18 Apr 2024 21:59:29 +
To: mutt-dev
Subject: Re: Message security; protected header fields
Message-Id: 
X-MARC-Message: https://marc.info/?l=mutt-dev=171347742508069
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--T/e8leAN/4bSvaex"


--T/e8leAN/4bSvaex
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 18 Apr 2024 23:59:29 +0200
From: Alejandro Colomar 
To: mutt-dev@mutt.org, neomutt-de...@neomutt.org
Subject: Re: Message security; protected header fields

Hi Derek,

On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote:
>g. Protecting the recipients is problematic for potentially several


However, I don't see that in your message, which means that either this
bug doesn't reproduce with your configuration, or you use a different
version of mutt(1).  Still, I find it interesting that mutt(1) messages
will be protected even if you don't patch mutt(1) --at least in some
cases--.  However, you won't be able to benefit from those protections,
since you don't use those headers at all.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Thu, Apr 18, 2024 at 08:16:15PM -0400, Derek Martin wrote:
> The message interception scenario is possible, but I think highly
> improbable, especially for the sort of people who are using Mutt and
> encryption--savvy users.  It requires the attacker have superuser
> access to the mail system somewhere between you and your genuine
> recipients, AND either be known to your recipients, or your recipients
> must have no idea who should be on the message.  The attacker needs to
> be able to prevent the delivery of the original, to have time to
> inject the bogus message.  And your recipients need to already have
> the attacker's public key and trust it, or be set up to automatically
> download and use untrusted public keys...  

Also, FWIW, I've been using Mutt and encryption for almost 30 years,
and I haven't heard of a single case where the way Mutt handles
encrypted mail caused someone embarrassment or loss.  Not to say there
haven't been any, but... at least if there were, not high enough
profile to make it HERE.

And to be honest, it's been my experience that your recipients are
much more likely to leak the stuff you sent them encrypted, through
their own stupidity/carelessness than because of any flaw in Mutt.
And yes, that has happened to me.  Be very careful about relying on
encryption to save you.  You're probably almost always much better off
just not saying whatever you thought you should encrypt.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Kevin J. McCarthy]

On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
However, I'd like to point out that mutt added basic support for 
Protected Headers in the 2.0 release, following the Autocrypt project 


Ah, sorry, it was originally added in the 1.12 release (5/2019)!  The 
2.0 release added additional headers to the list and made some other 
tweeks.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Kevin J. McCarthy]

On Fri, Apr 19, 2024 at 01:59:57AM +0200, Alejandro Colomar wrote:
BTW, now that I remember, while developing these things for neomutt(1), 
I found that mutt(1) has a bug (?) by which it does actually protect 
some header fields precisely in the way that I implemented them in 
neomutt(1), with the difference that mutt(1) does it on accident.


As Derek mentioned, mutt is in maintenance mode.  I don't have much, if 
any, time available to address issues except for genuine crashes or 
vulnerabilities.


However, I'd like to point out that mutt added basic support for 
Protected Headers in the 2.0 release, following the Autocrypt project 
spec at the time . 
Since then, undoubtedly, they've advanced the proposed spec, but I 
haven't followed it.


However, saying that mutt adds those headers by accident or as a bug 
seems a bit uninformed.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature