Random MIME boundary needed? (was: Security findings)

Hi!

On Tue, 21 Apr 2026 10:28, Kevin J. McCarthy said:

> If anyone has comments about #4, I'd appreciate feedback.  The email

>> - **Impact**: Cross-client MIME smuggling when user forwards attacker
>> email containing predicted boundary

I do not see the problem here.  If a mail is forwarded, the forwarding
MUA needs to make sure that the boundaries are unique in the the
forwarded message.  Usually a random boundary is suffieent here but it
does not harm to check for conflicts when generating the new boundary.

The forwarding MUA may change any boundary at will and construct a
different MIME tree.  But that is not different from creating mail from
scratch.

>> - **Attack**: Monitor user's sent mail → recover PRNG state → predict
>> future boundary → craft body containing it → recipient sees fake MIME

This is not a faked MIME structure but a MIME structure created by the
sender - what's the problem?

There is one place which may need attention: The case of forwading a
signed mail - the MUA may not change the bondary of the signed mail
parts.  Detection of duplicated boundaries is thus needed - or an
unpredictable RNG.  Note that tehre is no problem at all with encrypted
mails - because you get a new mime tree after decryption.

I see no attack here.  However, mutt_random_bytes is also used to
construct message ids.  I would suggest to make them less predictable.
But do not use new crypto algorithms for that.  All systems come with
proper random number generators these days.  Something like

  /* Create an unpredicable nonce of LENGTH bytes in BUFFER. */
  void gcry_create_nonce (void *buffer, size_t length);

if you anyway link to Libgcrypt, or use the respective functions from
the other crypto libs.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein

-----BEGIN PGP SIGNATURE-----

iJ8EARYKAEcWIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCaecp9RsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMSwyLDINHHdrQGdudXBnLm9yZwAKCRAZzByeCFsQencqAP9K
SdjYfCuY9syLUWl/gJejQeHeFekWQTbkuC86hHkIrwEAysZatuFTn9tyzGl/2+VT
vb/wj81vzwy1/9goe0qlJQw=
=fHd4
-----END PGP SIGNATURE-----