RE: TECH-OMISSION: Security vulnerability - Malicious DSN attacksHello again
Daryl,
Daryl Odnert commented:
Hello Chris,
I still strongly disagree that the vulnerability you are concerned
about is made worse by Sender ID.
In this TECH-OMISSION I am just asking that the _fact_ of this distinct
vulnerability be recorded in the draft. My personal judgements about how bad it
is remain as expressed in my ealier DEPLOY threads.
As you've explained, Sender ID
does add a new way to get a recipient's MTA to reject a message.
But there are already several ways to make this happen,
It's my belief that when a distinct security vulnerability is determined, it
MUST be recorded. Suppose someone found a solution to the other, related
vulnerabilities (e.g. the 'non-existent recipient'). This one would still
remain.
so I just
don't see this as a fair criticism of Sender ID.
Again, I don't see the full and accurate recording of security vulnerabilities
as being 'fair' or 'unfair'; these are factual assertions - to be proved or
disproved.
There is another, more positive comment I can make. This MARID activity is part
of a sysematic sweep through the entire mail system to counteract the many
abuses that have become prevalent.
It's my belief that, as we uncover and analyse problems we should record them,
recognise them within the RFC process, and then produce documented, tested
solutions to them.
So even if the earlier, related vulnerabilities have not yet been formally
recorded, that's no reason to ignore ones we do come across in the course of
this clean-up operation.
However, in the interest of clarity, I think that in your example,
you need to make it explicit that the participant P does not perform
any Sender ID test before accepting responsibility for relaying the
message from A,
Actually, I chose my words very carefully, to describe 'both' situations - test
failure during and after SMTP phase. I know that it is a different host which
actually sends the bounce in each case, but the overall effect is the same (with
the one difference in whose reputation is possibly suffering by being the actual
sender of the bounce).
nor does it add any RFC 2822 headers that would change
the Purported Responsible Address of the message.
I said that the attack is conditional on the attacker being able to chose a PRA
which will certainly fail. Changes in PRA along the chain which mean the
message test no longer fails are therefore outside of the scope of this
vulnerability.
I think you also need to make it clear that P would have to be
configured such that it accepts mail from submitter's IP address where
the MAIL FROM address is V and where the recipient address is in a different
domain (R) that might perform a Sender ID test on inbound SMTP mail.
Ah! I think we are getting stuck on this issue of when in the SMTP process cycle
the Sender-ID test is undertaken.
In preparing for this reply I re-read the 'core' draft and realised that they
have left undefined the behaviour if the test is undertaken in an MTA _after_ it
has accepted the message for onward transmission.
I have therefore just posted a TECH-OMISSION to the list correcting this
omission.
This message (and my original starting this thread) should be read as if I had
_previously_ posted that correction, so that testing before and after SMTP
message acceptance produced the same externally-visible behaviour (even though
the bounce may be send by different hosts in the two cases).
Normally, only MTAs that are operated by (or trusted by) V for outbound
SMTP mail processing would be configured this way. Therefore, the attack
is only likely to occur if it can be launched from an IP address that
normally submits mail from V to P.
I'm very sorry, I just don't understand this point.
Dues it change in the light of my comments / draft amendments above?
Daryl Odnert
Tumbleweed Communications
Redwood City, California
Chris Haynes