On Sat, 2004-08-28 at 21:26, Andrew Newton wrote:
On Aug 27, 2004, at 7:45 PM, Mark Shewmaker wrote:
So, is that suggestion something that could be included within
SenderID, perhaps in a security-considerations section?
For clarity, can you give the text you would like included in the
security section? I think this would better help in understanding the
problem and better help people formulate an opinion.
Sure.
=====================================================================
6.5 Vulnerability to unintended participation in Forged DSN attacks.
This vulnerability exists if local policy settings allow for a situation
in which all of the following are true:
- An incoming message was sent to multiple recipients,
- The message will ultimately be considered deliverable to some
subset of its intended recipients,
- The message will also be ultimately be considered undeliverable
to some other subset of the initial recipients, and
- The ultimate determination as to per-recipient deliverability
cannot be made until after the SMTP transaction accepts the
message for delivery.
Normally a delivery status notification would be sent to the given MAIL
FROM address, notifying it of the undeliverability of the message for
its specific intended recipients.
However, if the MAIL FROM address is forged, an innocent third party
will be the recipient of this delivery service notification.
A clever attacker can take advantage of this vulnerability by using any
machine with detectably differing local policy settings as an apparent
source of the attacker's forged DSNs.
Not only does this mean the ultimate victims will receive forged DSNs,
but the machine the attacker used to accomplish the forgery may become
known as a source of forged DSNs.
An MTA can completely avoid becoming a participant in a DSN attack in
all cases by:
Whenever all of the following is true:
- An incoming message is addressed to multiple participants.
- Those participants have local policy settings that,
given the context of the specifics of the MTA transaction,
mean that a per-recipient final determination of delivery
cannot be made until after the message has been fully accepted.
- The MTA has not positively validated the MAIL FROM address,
Then:
- The MTA should give temporary rejections at "RCPT TO:" time
to all recipients with differing local policy settings and where
the recipients have not already been temporarily or permanently
rejected for other reasons, (and where the local policy setting
difference can cause differing determinations of ultimate
deliverability), thus accepting only a compatible subset of
recipients and avoiding the need to create DSNs at all.
It is suggested that the MTA reject these recipients with a
return code of 4.7.6.
(Note that the MTA is not rejecting on the basis of too many
recipients, rather it is rejecting on the basis of a
security-related incompatibility in the requested recipient list.)
Given special-case conditions, there are simpler, alternative ways an
MTA can completely avoid becoming a participant in a DSN attack:
- If the client MTA sends a "SUBMITTER" parameter to the MAIL command,
then no per-recipient policy that addresses functionality related to
this standard can trigger this vulnerability. If per-recipient
policy settings only extend to functionality related to this
standard, then the above recipient-rejection workaround need not be
used for that SMTP transaction.
- If the server MTA obtains positive validation of the MAIL FROM
address for a particular SMTP transaction, then for that SMTP
transaction the server MTA need not use the recipient-rejection
workaround given above.
- If a future SMTP extension allows for per-recipient after-DATA
rejects, and an SMTP session makes use of such an extension, then
the above workaround is not needed for that session.
Avoiding the receipt of forged DSNs is generally outside the scope of
this document, however a domain that signs outgoing messages in a
recognizable way can avoid at least some types of forged DSN attacks.
=====================================================================
After writing all that, (and after seeing Chris Hayne's similar proposal
which he sent earlier today), I'm actually starting to rethink my position
as to whether this workaround should be listed within core at all. (!)
The reason is that in addition to affecting Sender ID, the above vulnerability
affects the general case of content-based filtering, so I'm wondering if
something
like the above would be better placed in a more general BCP as opposed to just
being included within Sender ID.
For the moment I'm not sure how to answer the above question.
I think the warning/workaround needs to be *somewhere*, but whether it should
be in core or in a more BCP, or both, I'm not sure:
o If it should be in core, then I want to push for something like
the above.
o If it should be in a BCP, well, then I'll push for it there,
(although I'm not clear on how to go about that.)
As the above question doesn't much change the existence of the vulnerability
and the necessity of the workaround though, I still submit my wording above
for discussion, dissection, and joyful mutilation.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com