Re: [secdir] Review of draft-freed-sieve-notary-07

[Ned Freed <[e-mail]>]

> Ned Freed writes:
> > > > The same arguments hold for DELIVERBY. If the extension is available, why
> > > > not just (ab)use it directly? Why bother with a convoluted path through
> > > > Sieve that will almost certainly leave a much bigger trail?
> >
> > > If the relayed status notifications go to the original author instead
> > > of the sieve filter owner, then the attacker does not need to send
> > > any emails, the victim attacks himself by sending email to attackers
> > > address which will then add trace option to the email on the fly.
> >
> > Now please explain the significant advantage this provides to an
> > attacker. It's not like sending emails is hard.

> (This dicussion is mostly background stuff, and as the new text says
> that redirect-deliverby uses Sieve owners address as envelope sender
> address this does not really matter anymore as that alone solves the
> attack.]

> Sending emails is not hard, but I have understood that Sieve is
> supposed to be something that can be safely enabled for any users even
> when they do not have too much capabilities in the system.

Yes and no. Sieve is specifically designed so that users can be allowed to
access it directly without being able to cause adverse impact to the email
infrastructure. Just as one example, the language isn't directly
Turing-complete, so you cannot write infinite loops of the "10 goto 10" variety
in it that will compromise your server by sending it into an infinite
evaluation loop.

But this doesn't mean you can just provide full and unrestricted access to
every Sieve capability and not have any problems. And this is true even if
you're talking about Sieve as defined in the base specification with no
extensions at all. A compliant basic implementation will provide the redirect
action, and nothing prevents me from writing a Sieve containing 100,000
redirects, one right after another, one to each person I want to spam. So every
competent Sieve implementation limits the number of redirects a script can
perform, just as an SMTP server limits the number of recipients it will accept.
(The very close parallel between this case and success DSN/delivery case should
be noted.)

What most implementations do to address this is to limit the number of
redirects allowed in a single Sieve. Typically this limit is set to 5 or so,
but it really needs to be a configurable parameter because the needs of
different installations in this regard are very different.

Moreover, such issues aren't limited to the actions the scripts can take.
Consdier the Sieve body test. I can write something like this:

   require ["body", "variables"];
   if header :matches "from" "*a*" {if body :contains "${1}b${2}" {keep;}}
   if header :matches "from" "*b*" {if body :contains "${1}c${2}" {keep;}}
   if header :matches "from" "*c*" {if body :contains "${1}c${2}" {keep;}}
   ...

In other words, I can write a script that does an arbitrary number of body
searches where the strings being searched for are dependent on the input
message in a very complex way that prevents precomputation and therefore forces
the Sieve implementtion to perform an arbitrary number of searches of what
might easily be a very large amount of text. (Our implementation provides body
tests but without the ability to perform variable substititions in the pattern
in order to prevent this sort of thing from being done.)

What this all translates to is that proper implementation and configuration is
still essential. You cannot operate an email system without proper and
consistent configuration and the presence or absence of Sieve suppport doesn't
change this fact in any way. And while it is nice to talk about a world where
such careful configuration of services isn't necessary, email simply wasn't
designed that way and you cannot make this happen after the fact. (Indeed, I
doubt it would be possible even in a blank slate design, but email is so far
away from that it's pointless to even think about.)

> For example lets say someone joins some mailing list and then make
> Sieve filter that will redirect all mails from that mailing list
> forward to some system using DELIVERBY with trace option. If those
> status notifications (lets say there are for example 3 email hops
> before the email reaches its final destination) go to the original
> author, this one Sieve user has very easily generated (even perhaps by
> accident) distributed attack against all mailing list users. Everybody
> sending email to this list will get 3 DSN notifications back from some
> hosts on the network which he does not have any idea why he is getting
> them and unless he really knows how to read email Received headers etc
> he does not even know who enabled the feature, i.e. who is doing the
> attack.

And once again, contrast this with an attack where I simply do the same thing
by sending a bunch of messages to the SMTP server directly using a problem on
my desktop system. No need to wait for the list to cough up the messages, no
audit trail showing how I edited my Sieve to make this happen - something
that's going to be hard to claim a virus or bot did, no need to worry about the
necessary extensions being there, etc. etc.

Really, this whole line of argument of yours is at best like worrying about a
pinprick when there's a deep stab wound right next to it.

> Yes, the original attacker could do the same thing with procmail or
> .forward and simple shell script, but I understood one of the reasons
> for Sieve was that it was supposed to be safer for "normal" people to
> use it and not cause problems, i.e. it is used in environments where
> shell access is not provided.

The difference between Sieve and procmail or .forward isn't that Sieve is
incapable of being abused. It's that Sieve is designed in such a way that you
can actually prevent various forms of abuse with proper implementation and
configuration. Procmail in particular is impossible to secure in a similar
fashion: It's regex-based and it's trivial to write regexes that will consume
vast amounts of CPU, and moreover you can construct problematic patterns where
their problematic nature is difficult if not imposisble to detect in advance,
it allows execution of arbirary shell scripts, no consideration was given to
the ecurity implications of the built in action set, etc. etc. etc.

It is fair to say that Sieve probably wouldn't exist had procmail been designed
with safe server-side operation in mind. But it wasn't.

> Also as the distributed machines sending those DSN notifications are
> real legal email servers which normally do process emails (in or out)
> the original sender getting those DSN's does not want to filter them
> out (or not even all DSN from them machines, as somethings he himself
> might want to enable DSNs and get DSN reports back from those machines
> too).

In almost every real world case it is going to be same set of servers the
user has direct access to.

> The problem is not very big, I agree, but if Sieve is supposed to be
> system which can safely be given to the "normal" people who are not
> allowed to get shell access to email systems, then this does offer
> them new way of causing trouble and harm to other users (i.e. the
> original sender). This is why I think it is issue which might need to
> be mentioned here but as I said already the new text which says
> redirect-deliverby uses Sieve owners address as envelope sender solves
> all of this already as now Sieve owner can only attack himself...

With all due respect, I think you're operating from a seriously outdated attack
tree here. The whole shell access on the server thing is only really relevant
these days because of the potential for local resource consumption and
privilege amplification attacks. The presence of a scriptable PC on almost
everyone's desk has eliminated the need for direct server access to perform
more general sorts of automated attacks. That's why the SMTP server has to be
properly secured irrespective of what Sieve does or doesn't allow, and the only
relevant case is where Sieve offers most access than regular SMTP does.

> > > Say host A limits DSN notification complately, i.e does not allow them
> > > at all. Now host A user A sends email to user B on host B whose sieve
> > > filter adds status notifications (as they are not restricted on host
> > > B, only on host A) and the status notifications go to original author
> > > A. Now host A user A will get status notifications even when the host
> > > A policy forbid requesting them.

> > In other words, this is a case where the Sieve policy for requesting
> > DSNs is more lenient that for submit/SMTP. I agree this is a
> > security concern, which is why the security considerations section
> > of the document addresses it. It says:

> >   Sites which limit the ability
> >   to request success notifications will also need to restrict the ability
> >   to request them using the redirect-dsn extension.

> > > Host B cannot know what policy host A has, thus it cannot restrict
> > > operations.

> > Not only can it know, it has to. This is what administrators are for
> > - to implement consistent policies across hosts.

> Ok, do my home machine kivinen.iki.fi allow DSN or not? When I send
> this email to you, is your Sieve filter allowed to add DSNs to this
> email or not, i.e. do you know whether my outgoing email server
> allowed me to enable DSNs or not.

If the servers I have available to me don't allow me to make DSN requests, I
would not expect to be able to do it from Sieve either. Ditto for DELIVERBY.
And if this isn't true, we're back to the case explicitly covered in the
security consideations.

> In general case you do not. I have understood that Sieve is normally
> run on the receiver end of the email, but perhaps I have misunderstood
> that. The DSN policy is for the sender end of the email transmission.

The DSN policy on the sender end is irrelevant, because Sieve has no access to
that end of things. It has to submit the DSN request to the local submit
server; Sieve provides no means for the user to select the submit server
that's going to be used.

Come to think of it, this is another way where any potential vulnerability in
Sieve falls far short - if I want to I can usually bypass local admimistrative
policy entirely by submitting my message with the forged envelope sender
directly to a server in another administrative domain. There's no way to do
that in Sieve.

Again, Sieve acts a a proxy for the user, providing another means for the user
to send mail. If this alternative means of  sending mail is for whatever reason
more permissive to the point of allowing abuse the regular SMTP server does
not, that's a configuration problem that needs to be addressed.

> Very often there is no common adminstration between the sender and the
> receiver as people DO send cross-domain emails...

Of course there isn't, but since the Sieve isn't operating in the sender's
administrative realm, it's irrelevant.

> Again this point has also gone away now when the Sieve owner's address
> is used as envelope sender as now the machine running Sieve can know
> the policy to be used.

And again I assert that this supposed security never existed in the first
place.

> > > > > Also in section 5, it should be made clear that the "bytime" can also
> > > > > be negative, if the bymode is "notify" and the message is already
> > > > > pasts is notification time.
> > > >
> > > > Unfortunately, RFC 2852 predates the current thinking in email that
> > > > there's significant semantic difference between submission and
> > > > relay. My understanding of the purpose of negative by-times is that
> > > > they are arrived at when a message exceeds the time limit but still
> > > > needs to be delivered. If there's a justification for having a
> > > > negative by-time on initial submission I haven't heard it. In fact
> > > > had RFC 2852 distinguished between submit and relay I suspect it
> > > > would have disallowed negative by-times in the submit case.

> > > I do not thing this is relevant here.

> > On the contrary, it's entirely relevant because what we have done by
> > requiring the resetting of the envelope sender is to effectively
> > require that these extended redirect be considered as a new
> > submission, not a relay operation.

> Ok, that I can agree, but I assumed you were processing these two
> issues independently and without the first change (i.e. the envelope
> sender change) this would be different.

I have no idea what this is supposed to mean.

> > > It might be needed if the sieve filter wants to preserve by-time
> > > values given to it in the beginning. I do not know enough of Sieve to
> > > know if it is possible, but one use could be using sieve to for
> > > example limit the by-time to something, i.e. wants to make sure that
> > > when email is redirected to cellular phone it is delivered before
> > > certain time (for example before 22:00, because user does not want to
> > > wake up when cellular phone beeps in the middle of night), unless the
> > > email already had shorted by-time, in which case it wants to preserve > it.
> >
> > The short answer is ths use-case you describe here really isn't feasible
> > in Sieve, for a bunch of different reasons.
> >
> > THe longer answer is that this ends up being infeasible because:
> >
> > (1) Sieve doesn't have enough numeric and time computation facilities to
> >     perform the sort of limit operation you describe.

> And there is not going to be extensions offering such features, like
> adding and substracting integers and comparing them, and getting the
> current time?

Well, of course that's impossible to predict, but despite there being a huge
number of proposals for Sieve extensions, dozens of drafts, and many RFCs,
nobody has even suggested such a thing, let alone written up a draft. And we
appear to be coming to the end of Sieve extension work. So I think the odds of
it happening are pretty low.

That said, I think there may be a way to do this without arithmetic as long as
you can get the comoonents of the by-time in absolute form.

> > (2) Even if you could do the calculation, or if, say, there was a related
> >     use-case where limiting the relative value made sense (I confess I cannot
> >     come up with one where it does), most Sieve implementations operate
> >     after final delivery, so copying deliver-by information doesn't really
> >     make sense.

> For the user who is redirecting this to cellular phone it does make
> sense.

I first note that the action of "redirect to cellular phone" is rarely if
even what's actually going on. And in this case it's an important distinction.

What actually occurs is that the message is sent to a submit server and back
out into the transport infrastructure. Eventually the message gets delivered to
a mailbox somewhere. And there it sits until the client polls and  finds the
message. The time spent waiting for that poll to occur is time that is not and
cannot be controlled by DELIVERBY.

Of course there are alternatives to polling. The standard ones are IMAP IDLE
and NOTIFY. But both IDLE and NOTIFY require that the client hold open a
connection to the server. That's highly problematic for cell phones so most of
them don't do it.

Absent IDLE or NOTIFY, you're left with nonstandard mechamisms. Unfortunately
most of this stuff is highly vendor-specific and what I little I do know about
it is covered by various nondisclosure agreements. But suffice it to say that
the availability of such capabilities is far from universal, and the quality of
the resulting services can vary considerably.

And even if the client is notified immediately, it may not for various
reasons be able to get at the message right away. And again, all of this
is happening outside of the supervisory control DELIVERBY provides.

Even if we assume none of these delays occur - and it's my current experience
that these days delays post final delivery are far more prevalent than
transport infrastructure delays - there's the question of intended semantics.
DELIVERBY can be used to say, "Deliver this message by such and such a time, if
not, give up". But why this is being done isn't part of the package. You may
infer that what the sender cared about was getting the message in front of the
recipient's eyes in a certain amount of time, but what if the goal was merely
to get the message into the recipient's mailbox before some deadline and the
sender could not care less if they have seen it or not? The protocol doesn't
let you make that distinction, and that makes willy-nilly copying of DELIVERBY
information acrsss resubmits problematic.

There's also the issue of Sieve NOTIFY. IF notify is available, not only can
you use it to send a notification about the message to the phone in a way that
avoids most if not all of these issues.

What you're left with is the case where (a) The sender's intentions are known
in advance, (b) DELIVERBY is unformly supported across both transports, (c)
Sieve and this particular extension are also supported on the initial delivery
server, and (d) Post-delivery delays are negligable, and (e) No better
alternative like Sieve notify are available. While I'm sure such situations
could exist, this is now a pretty esoteric case.

> Lets say the email is about meeting that starts at 18:00, and
> because of this the original deliver-by-time is 18:00, i.e. this email
> is useless after that time. This email arrives to the users Sieve
> filter at 14:44, and it is stored to users mail box, and the user's
> Sieve filter wants to send a copy of that to cellular but add
> additional limit that it cannot be send after 22:00 (just in case
> there is some delays there), so user wants to add new deliver-by-time
> that is going to be 22:00, but as the original had deliver-by-time of
> 18:00, it would be better to use shorter of those two as even when the
> email is already delivered to the final destination (users mail box)
> before the 18:00, the copy sent to be out usually has exactly same
> meaningful time period as the original email. It does not help the
> user to get that email to his cellular phone at 20:00 when the meeting
> is already over. Because of this it does not really matter whether
> this is final deliver or not as user still would have interest to use
> the earlier of the two deliver-by-times.

I understand the use-case. What I'm saying is that it's a lot harder to
implement than you think. And while you can argue that it shouldn't be, the
real difficulties here have nothing to do with this extension.

> (I used absolute deliver-by-time in the example above as it was easier
> to explain using that, but of course the Sieve filter itself could as
> easily use the delta time too.)

As a practical matter, yes, but once you capture a relative time you're no
longer accounting for the time elapsed between when you captured it and when
you use it. Since one of the main points of Sieve is that all scripts can be
executed in negligable time, this is not a realistic concern, but there's still
a gap.

So really, the best way to do it is with an absolute time, which you need
anyway to perform the necessary comparisons.

> > Actually, no. In the use-case you describe, the goal is to prevent the phone
> > from ringing after a certain point. That implies that a by-mode of "R" has to
> > be used, which means no negative by-times are allowed.

> True.

> > Moreover, if the original mode was "R", you can copy over a shorter by-time.
> > But what happens if the mode is "N"? I think in that case you'd want to
> > ignore the original by-time in order to get sensible behavior.

> Most likely. Or you just take shorter time and use R in that case too,
> as if this is copy the email is already delivered to Sieve users mail
> box, but this is for the Sieve user to decide. Of course all this is
> also related to where the status notifications are sent. As with the
> current change the status notifications are always sent to the Sieve
> owner, so he most likely would be using R always in this setups as
> this "cellular phone" is supposed to be the way to reach him more
> quickly than from normal mail box, and N notifications does not really
> offer any new information for him.

> > All that said, this use-case makes me wonder if the real error here
> > is that we aren't providing a way to look at and set by-times as
> > absolute, rather than relative, time values.

> I actually start to feel that it might be better option.

It's a better option for several additional reasons, one being that this way
yuo can do much simoler and more obvious stuff like redirect a message that has
to be delivered before 10:00PM to do. That's impossible to do currently, but it
can be done if you have an absolute time argument variant on redirect.

> > > Also I think the Sieve should be able to preserve by-time and envelope
> > > sender when it redirects email, if it does not ADD new notifications.
> >
> > > I.e if someone sends email having by-time saying it needs to be
> > > delivered during next hour, and the Sieve forwards it to the cellular,
> > > it would be useful to keep that same time limit there, and it would
> > > also be nice if the original author still gets the status
> > > notifications he asked for.
> >
> > That's totally outside the purview of this extension, which does not
> > and cannot deal with the unextended redirect case. Moreover, the
> > lack of specificity about when Sieve operates - which is both
> > intentional and essential - makes this a very difficult question to
> > address in ANY context. Just as one example, you most certainly do
> > NOT want to try and preserve these things if Sieve is operating in a
> > user agent weeks after final delivery - which is a perfectly
> > legitimate and even common situation.

> Ok.

> > > If the email is not yet delivered to the local mail box, but is
> > > redirected to somewhere else by the Sieve then I do consider the email
> > > to still be in transit, and the time used to run the Sieve should be
> > > taken in to account. In most cases it does not really matter as
> > > running it is very fast, but I think it still needs to be counted for.
> >
> > Sieve implementations that operate at this point are in fact the exception,
> > not the rule.

> So perhaps saying something that when Sieve is run as part of transit
> then the delta time should be decremented. Btw, this will be
> automatically taken account if the delta time is converted to absolute
> deliver-by-time when the email is received and then back to delta time
> when it is sent forward as part of relay.

It's actually better for the reasons I gave above.

> > > > I think this makes it clear the values are simply passed unchanged
> > > > to the SMTP/submit server. But if you want to suggest a specific
> > > > change, that's fine.
> >
> > > I think RFC 2852 is very clear that you are supposed to convert that
> > > DELTA time to absolute time upon receipt of email, and then convert it
> > > back to delta time when you send email forward:
> >
> > Yes, I'm well aware of what it says, and why. I carpool to work
> > every day with the guy who wrote it. The reason for this text is so
> > that implementations won't carelessly lose track of some amount of
> > elapsed time. But again, this only works while messages are in
> > transit. I'm not convinced there's an issue worth addressing in the
> > Sieve case.

> Not even those exceptional cases where Sieve is run as part of email
> transit, not as part of final delivery?

Not even then. See above for why this is a lot more esoteric than it first
appears.

				Ned