ietf-mta-filters
[Top] [All Lists]

Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt

2007-09-05 18:05:43


I think we are talking past each other a bit so it might be very helpful to have a phone call at some point. Let me make sure that I got what you are saying here at the high level - I think your position is roughly the following:

If implementors follow the advice that Lisa put in the RFC Ed note (what Alexey and you had sent), then it is still possible to have massive mail bomb style attacks using SIEVE but in practice this is not an issues because of a few things including 1) it is not the weakest link of the email infrastructure and other things are attacked first 2) it is no worse than currently deployed things 3) logging can help with removing the the offending accounts after the fact. By massive here I mean something more like 2^100 not 100 messages.

Do I have that about right?


On Aug 30, 2007, at 7:37 PM, Ned Freed wrote:

> As a specific example, I have
> email accounts at Sun, on my home systems, Gmail, and a bunch of
> other places.
> All, I repeat _all_, of these services allow me to easily configure
> autoforwarding to multiple destinations.

Uh - you sure.

Yes, as a matter of fact I am sure. I try very hard not to make assertions
without the facts to back them up.

I'm not aware how to make gmail go to multiple system

It's trivial. Hit the settings tab at the top right and then create two filters. Use whatever critera you like and have one that forwards to address A and the other to address B. Before I included gmail in my response I tested this with two non-gmail accounts I have elsewhere and gmail happily forwarded a test message to both. No warnings, no problems, just two copies of the mail. I just checked my account again just now and the both forwards are still in place and working. Here's approximately what my settings page has to say about it:

 The following filters are applied to all incoming mail:                
 Matches: subject: vvv
 Do this: Forward to xxx(_dot_)xxx(_at_)yyy(_dot_)yyy

 Matches: subject: vvv www
 Do this: Forward to zzz(_dot_)zzz(_at_)aaa(_dot_)aaa

I can't really talk about the specific ISPs we have as customers and their policies, but I can assure you gmail is not alone in offering this capability to their users. To the extent offerings differ, the difference seems to be whether or not users are allowed to configure custom filters at all, not whether or not setups that allow custom filtering configuration can forward. Hotmail, for example, effectively doesn't offer custom filter settings, so it
is hardly surprising that they don't offer forwarding.

which is of course the important one because the others systems have
relationships with you and other ways to secure things by causing bad
consequences for you if you abuse the system.

I don't believe this is as much of a difference as you seem to think. Quite a few of the cases of mailbombing I've seen have been disgruntled employees and the like attacking their own company's systems. (AFAIK none of them involved the use of sieve redirect, but that's really beside the point.) Apparently nothing says "I quit" quite like a mailbox with 10 million pieces of hate mail
in it.

> If memory serves, your suggested way to prevent it was to allow at
> most one redirect operation to be done during the execution of a sieve
> script.

Well, what I have in my notes from the prague meeting was "Told them
I was OK with SHOULD not redirect to more than one location outside
the domain".

And I responded that I think that goes too far and isn't reasonable. In particular, a SHOULD that fails to take into account that there are legitimate use-cases for mutlple redirects makes the entire specification look incompetent and serves to weaken the effectiveness of all the other advice we give.

We may have different ideas about what domain means but
roughly I would mean administrative domain - certainly I would call
an enterprise or large bank one domain even thought they might have
separate DNS domain names for different locations or something. You
might use the term "onsite" where I used domain.

I don't think the restriction to a single domain, regardless of what domain means, accomplishes nearly as much as you seem to think it does. Again, to the extent mailbombing is an issue, in my experience it's as much of one within an
ADMD as outside of it. Perhaps more.

> And you've been told that this is simply not acceptable - there are too > many use cases for forwarding email to two different places at once.

Actually, I have received very little comment on if this is
acceptable or not. I have mostly recieved something that loosely
translated to "the WG disagrees with your discuss". I would be very
happy to talk what my concerns are and have folks figure out if their
is a solution that addresses them and still meets the bulk of users
needs.

Then there has been a disconnect getting WG comments back to you. Several
comments were in fact made, including but not limited to one from me.

> In fact this is an
> incredibly common thing for people to do for all sorts of
> legitimate reasons,
> including but not limited to:

I suspect what I had proposed meets all these use case but don't
claim to really know. Glad to be educated.

OK, let's go down the list and see how ADMD restrictions fare:

> (1) Making messages accessible in multiple ways, e.g. send one copy to > my email account and another to my pager. Or voice mail. Or printer.
>    Or FAX.

A very common case is for pager, fax, or voice mail services to be outsourced to an external service provider. Often as not different people in the org will use different providers for this stuff. This is especially true if we're talking about a hosted setup. ADMD restriction cannot possibly work here.

> (2) Secretaries who need copies of their boss's email.

ADMD restriction are mostly compatible with this use-case.

> (3) Maintaining multiple mailboxes during a service transition
> period. Or two pagers.

This would depend on the nature of the transition. I've seen transitions to another ADMD as well as transitions within an ADMD. Domain restrictions are
problematic in this case.

> (4) Making backup copies of mail to address reliability issues (IMO
> this is not the best way to solve this problem but it is commonly done
> this way regardless of what I think).

In many cases the entire point of doing this sort of thing, especially at the
user level, is to get a copy of your mail to a place that has separate
administative controls. ADMD restrictions would be hugely problematic
for this use-case.

> (5) Making copies of stuff for law enforcement use (garden variety
> forwarding is a piss-poor way to implement this but it is nevertheless
>    something people do fairly often).

(uh, yah, laughing about how well this will meet some US Law
enforcement requirements :-)

I can't get into details, but the truly amazing thing is that I've seen situations where law enforcement _insisted_ on it being done this way even when a technically superior solution was available. (I'm actually writing a response to a proposal that's basically a variant of this idea in another
window.)

I don't actually know if the cases where this has been done involve forwarding outside the ADMD or not. (To be honest, I try very hard to learn as little about the operational details of interception activities as I possibly can.) But given the complete lack of clue needed to even consider using this approach I would not be at all surprised if such forwarding has been done in this case.

> (6) Vacation-time forwarding of important messages to the "next
> tier" of handlers.

This is usually done inside the ADMD but not always.

Tallying up, restricting autforwarding by domain didn't fare so well against this list of use-cases. So we're talking about a mechanism that is ineffective against a significant subset of actual attacks as well as being incompatible
with a lot of completely legitimate things people like to do.

Yet another problem with domain restrictions is that it is easy for them to turn into a violation of the least astonishment principle. ADMD boundaries can be complex - I've seen setups that consider thousands or tens of thousands of domains as local - and asking users to understand complex boundaries is in effect asking for a lot of support calls. And SPs will do almost anything to
lessen the number of support calls they get.

...

I'm not surprised - this all seems very consistent with my
discussions to these types of folks. I assume you also have the
discussions with the people like Yahoo, MSN, gmail, around the
policies they put in place to stop their servers from being used in
DOS attacks?

The people I talk to tend to be large ISPs rather than these sorts of SPs, but yes, we talk about DOS attacks a fair amount. However, the issue of the ISPs own infrastructure being used in the ways you envision for DOS attacks has almsot never come up, for the simple reason that it is not a significant issue
for them.

I know I have been dragged into a few theses - can  you
provide some insight around policies there?

OK, let's look at email DOS attacks in a bit more detail. Let's start with what sounds like a silly question: What does an MTA do? The answer, of course, is that it transfers messages around. It follows that if an MTA is good at its job it has to be able to accept and process messages fairly quickly. And this is in
fact the case: It isn't at all difficult to get performance of 50
messages/second on a single box. With a little more effort you can kick things up into the 500 messages/second realm (the main issue at this point is spam and virus scanning performance) and MTAs have been built that can handle well over 2000 messages/second (at this point threads and filesystem performance become
the bottleneck, requiring a bunch of exotic tricks to deal with).

MTAs are also built defensively, and the primary defensive stategy is to try and stop the bad stuff as close to the security perimeter as possible. The further in stuff gets the more resources have to be expended dealing with it. For example, when a user goes seriously over quota the best thing to do is turn back mail with a 4yz (temporary) error, not accept it and hold it until they go under quota again. Various rate limiting strategies are useful here as well and in practice are widely deployed. So unless your attack has both a distributed source and destination there's a very good chance it will be quickly detected
and blocked.

The bottom line is that modern MTAs are very good at handling lots legitimate SMTP transactions and take all sorts of steps to prevent themselves from being overwhelmed by too many of them. So attacking the email infrastructure by performing lots of real transactions is in effect a frontal attack against the most heavily fortified part of the entire system. This is not a recipe for
success.

So if frontal attacks don't work very well, what does? What we commonly see are attacks on various server resources: Connections, threads, processes, memory and disk. If an attacker can consume enough of some resource they can bring the servers down or at least make them very slow. For example, one attack we saw a while back was to send an infinitely long message - some MTAs buffer messages in memory and done right this could consume all available swap space and hang the server. Or there's the trick of opening lots of connections but never sending any data. Or stopping in the middle of the transaction. (This one is apparently popular right now - I have no idea why.) Or sending commands R E A L L Y S L O W L Y. Or attacking the network stack with malformed packets, incomplete TCP exchanges, and so on. Or simply overwhelming the network itself with data. Or causing the MTA to overlaod some other service, e.g. kill the directory server by sending lots of RCPT TOs and forcing lots of lookups. Or exploiting some known flaw in a particular implementation, e.g. blowing a vital cache by doing something to invalidate its content. The list is long, and if the attacker is highly distributed some of these are very difficult to defend
against.

But now let's consider where autoforwarders fit into this attack tree. First of all, since email is store and forward you cannot get an autoforwarder to perform anything but an actual transaction, corresponding to a direct frontal attack - exactly the attack MTAs are best at preventing. Even worse (for the attacker), autforwarders don't provide an attacker with much flexibility in terms of either distributing either the source or destination of the attack: Automating account and filter creation is in most cases difficult if not impossible, making the task of getting enough autoforwarders in place very time consuming and error prone, and most autoforwarders, including Sieve redirect, can only forward to a fixed set of destinations - the redirection cannot go to an address that's pulled out of the message itself. (The sieve variables extension changes this, but the topic at hand is what's possible in the Sieve base specification, not what some extension allows.) Finally, the people who offer autoforwarding as part of their service are as a general rule not morons and will probably notice if a large volume of email starts coming in only to be
forwarded right back out.

The bottom line is that, your beliefs to the contrary notwithstanding,
autoforwarders just aren't that interesting of a tool for attackers. This has been largely true throughout the history of email, and in the present world of botnets it is more true than ever. The folks at Cloudmark (who know far more about the attack landscape than I do) told me a couple of weeks ago that the botnets out there are now so large that devastating results can be had even if each infected system only sends out 5-6 messages a day. Given this why would any attacker even bother making autoforwarders part of their attack toolkit?

>> I believe that
>> the IETF has clear consensus that it does not want to deploy
>> technology that could trivially be used for large scale DOS and
>> message amplification attacks with very little safeguards or
>> traceable ways of dealing with this.
>
> This presupposes that there's a real risk here and that the necessary > safeguards are not in place. I don't believe either of these are true.

So far no one as sent me any information arguing these are not true.

Say what? My responses have contained exactly this sort of information and argument. And AFAICT you have yet to effectively refute a single point I have
made.

> > Now my current judgement call is
> > that this is in that category and could cause harm to the internet.

> But we're not dealing with a new protocol with zero operational experience here > where such judgement calls are our only means of assessing possible risk. > Rather, we're not only dealing with a protocol that has signifcant deployment > and operational experience, we're talking about a particular feature that's > been an integrall part of email for decades and is accessible in all sorts of
> ways besides Sieve.

Sure - and clearly if it is not a problem, it is stopped somehow, I'm
asking the Security section to provide some advice about how this is
all stopped.

Leaving aside that this is a fairly significant change in position on your part, the problem with this is that your reasoning rests on an unwarranted assumption: That the reason it is not a problem is because people have taken specific steps to prevent autoforwarder abuse. The fact of the matter is they haven't done this. What has happened instead is that the myriad of other measures people have taken to prevent attacks on the email infrastructure have collectively managed to make autoforwarders a fairly uninteresting tool for
attackers.

> First, nobody is claiming that autoforwarders cannot be used as an amplifying > component in various sorts of attacks. They can be used this way. This was true > for email decades before Sieve came along and it will continue to be true no
> matter what we do in this document.

yet somehow widespread message amplification attacks from email are
mitigated to an currently acceptable level.

Yes, because the measures people take to defend against other, far more pernicious attacks end up defending against autoforwarders vicariously. Defending against mail loops, for example, does more to limit the effectiveness of autoforwarders as an attack mechanism than any other step you can take. But if you don't have reasonable loop detection in place you will quickly find that
autoforwarders are the least of your problems.

> Second, nobody is claiming that script analysis can be used to prevent people > from abusing Sieve as part of such attacks. It simply cannot be done.

agreed - let's make sure the draft does not suggest people do it

I have no problem with that.

> More generally, the days where email systems can get away without producing > comprehensive logs and audit trails ended a long time ago. I have no idea > what you're basing your assertions that such attacks would not be tracable > in modern email systems, but it runs absolutely contrary to all of my
>    recent experience.

Certainly agree with you in enterprise case but in  a public provider
such as yahoo, sure they have logs but they may not have any way to
tying that to an actually human associated with the account.

But even if they had the information they still aren't going to go after most abusers - law enforcement could not care less about this stuff and a civil suit is way too much trouble for way too little gain. All they're going to do is
shut down the account.

BTW, the same is often true in the enterprise case: If some guy uses a mailbomb to say "I quit" the odds are pretty good the company will simply clean up the
mess and move on.

In any case, the point of having good logs is to be able to identify and stop
bad behavior. Catching and punishing the person responsible is a whole
different matter.

This is great - few bits inline below...

> Allowing a single script to redirect to multiple destinations can be > used as a means of amplifying the number of messages in an attack. > Moreover, if loop detection is not properly implemented it may be possible
>    to set up expontentially growing message loops. Acording, Sieve
>    implementations:
>
> (1) MUST implement facilities to detect and break message loops. See > RFC 2821 section 6.2 for additional information on basic loop
>        detection strategies.

My discuss did not ask for this but it certainly seems like a good idea.

Alexey already pointed out that you did in fact ask for this.

>
> (2) MUST provide the means for administrators to limit the ability of > users to abuse redirect. In particular, it MUST be possible to > limit the number of redirects a script can perform. Additionally, > if no use cases exists for using redirect to to multiple destinations,
>        this limit SHOULD be set to 1. Additional limits, such
> as the ability to restrict redirect to local users MAY also be
>        implemented.

We are very close here. If you changed the  "Additionally if no use
cases exists for using redirect to to multiple destinations this
limit SHOULD be set to 1." to "Scripts SHOULD be limited to at most
one redirect that is not 'onsite'". And define onsite somewhere. I'd
point out that this is a SHOULD not a MUST and that it could be
ignored if people understood the security implications of what they
were about to do. This could also possibly be coupled with idea after
next point to explicitly allow multiple redirects in some cases.

My problem with this is that "onsite" or "within the domain" or whatever should not be conflated with limiting the extent to which users are allowed to use redirect. I actually think you have substantially weakened the impact of this
guidance by over-emphasizing domain restrictions.

> (3) MUST provide facilities to log use of redirect in order to facilitate
>        tracking down abuse.

I would ask if this mean that they MUST know what human the script
was associated with. If yes, it is way beyond what I am asking for
and if no then hard to see how it helps.

On the contrary, this is arguably the most useful advice we have to offer. Real time as well as offline analysis of logs is in practice one of the primary tools that's used to find and eliminate email abuse. We actually spend at least
as much time advising our large ISP customers on how to do this more
effectively than we do on how to set up rate limiting or any other sort of defense. (And as I mentioned previously, our ISP customers have demonstrated no interest whatsoever in administrative limits on redirect. And we'd know because
it turns out the limit option wasn't documented.)

When I mentioned months ago
I could imagine many ways to solve this, coupling this type of thing
to the ability to do more than one redirect was one of the things
that seemed like a possible solution (and corresponds to my
understanding of at least some current deployments).

In conclusion, Alexey has proposed new text in a separate messagage which
I find completely acceptable. Please take a look at that and let's see
where we are.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>