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: - <https://github.com/neomutt/neomutt/issues/4223> - <https://github.com/neomutt/neomutt/issues/4226> 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. - <https://github.com/neomutt/neomutt/discussions/4251> This PR addresses both security vulnerabilities: - <https://github.com/neomutt/neomutt/pull/4227> There are other spin-offs of that discussion, including the following issues and PRs: - <https://github.com/neomutt/neomutt/pull/4221> (this was a debugging feature that led me to this rabbit hole) - <https://github.com/neomutt/neomutt/issues/4242> - <https://github.com/neomutt/neomutt/pull/4243> - <https://github.com/neomutt/neomutt/pull/4247> - <https://github.com/neomutt/neomutt/issues/4234> - <https://github.com/neomutt/neomutt/issues/4237> - <https://github.com/neomutt/neomutt/pull/4249> - <https://github.com/neomutt/neomutt/pull/4256> - <https://github.com/neomutt/neomutt/pull/4248> - <https://github.com/neomutt/neomutt/pull/4255> 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 <a...@kernel.es> *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 0000000000000000 *7 | [-- End encryption information --] / [-- Begin signature information --] Good signature from: Alejandro Colomar <a...@alejandro-colomar.es> aka: Alejandro Colomar <a...@kernel.org> aka: Alejandro Colomar Andres <alx.manpa...@gmail.com> 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 <a...@kernel.es> *8 \ \ Sender: f...@foo.com | | Reply-to: f...@foo.com }-|-{- Weed: weed && &crypt_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 hidden recipients. *8: AddressLists should be protected. *9: In-Reply-To should be protected. *10: Unprotected fields should NOT be trusted when replying. *11: This warning should be relatively easy to implement, I think. We're also discussing a few other improvements, such as using colors, but I'll let you find those in the neomutt(1) discussion page. Here's the most basic stuff only (anticipating that mutt(1) may not want to go fancy). Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
