On Wed 08/Mar/2023 22:27:57 +0100 Ángel via mailop wrote:
On 2023-03-08 at 11:24 +0100, Alessandro Vesely wrote:
On Tue 07/Mar/2023 20:02:48 +0100 Slavko wrote:
Why do you sign Content-Type: since you know it is going to be
changed?
Do you mean exactly me, or it was generic question? If you mean me:
Do you want change the text/plain message, eg. to multipart/alternative
with text/html appended? Of course, in my case that change will invalidate
body signature too (as i sign whole body), but anyway, it constructs core
of message, thus (IMO) fulfill RFC.
Yes, I meant you, since you (are among the ones who) do it.
The change to multipart can only happen using the deprecated l=. It allows to
completely replace the body appearance. As you don't use l=, the only added
protection is against an improbable collision between the original bh= and the
hash of the modified body.
There are more ways to change a Content-type for abuse.
Suppose there is a web form that is expected to send a plain text message
saying:
"Hello Alessandro
Thanks for registering on example.com, please click the following link to validate
your account: https://example.com/register...";
These kind of forms are already abused by using "names" such as "buy our viagra
at great price on http://spamurl.com";
URLs don't depend on Content-Type:, do they?
The "I received a scam letter from Paypal" thread a few months ago is also based
on the same concept.
That turned out to be authentic, IIRC.
Now, let's suppose that email is DKIM-signed but the Content-type: text/plain header
is not. And the form is filled out by «Bobby <style>* { color: white; background-color:
white; } .phish * { color: black}</style><div class="phish"><h1>Important notification from your bank</h1>
<p>Your password has expired. Please <a href="https://phishing.com";>Renew it here</a></p></div>»
and attacker changes the Content-type from text/plain to text/html...
Is that content going to replace «Alessandro» in the plain/text message from
the generated message? The culprit seems to be rather the input sanitizing
than the signing.
Another venue would be changing the charset to utf-7 This was a common
way of bypassing XSS filters on browsers. It is now unsupported by all
browsers, and forbidden by the spec [1]. I don't know if there is any
MUA which allows that (or even used to support it)
That requires the original text to already contain the exploit. Perhaps the
plain text message was exemplifying it?
Determining which headers to sign (or not to sign) is complex, brittle
and reasons for that unintuitive and not well-known. A reference
document that provided guidance (if not even a direct recipe) would
surely be helpful to the email community.
I agree that some kind of transactional messages can bear paranoid signatures.
They also deserve p=reject.
Ordinary messages, which can expect to be forwarded or slightly modified could
keep a lower profile, couldn't they?
I understand that the only advantage of signing lightly is for the very few
people who can recover that kind of signatures after MLM transformation, so it
seems to be a lost argument...
1-
https://html.spec.whatwg.org/multipage/parsing.html#character-encodings
I hope Javascript in email messages does not run...
Best
Ale
--
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
