Subject: security review of variables

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 01 Jun 2005 17:43:50 +0200

this is an attempt to summarise the feedback received from security
reviews by Love Hörnquist Åstrand, Sam Hartman and Jeffrey Hutzelman,
and with input from Alexey Melnikov.

the main (only) issue was the behaviour of length limits.

        how does modifiers to SET interact with length limits?  current
        modifiers can't increase length.

        variables which exceed implementation limits are silently
        truncated when stored.  there is no way for a script to discover
        implementation limits and take appropriate action.  among the
        reviewers, there was consensus that at a minimum the security
        aspects of this behaviour needs to be documented.  an
        alternative suggestion was to establish a namespace where such
        implementation values can be looked up.
        
        there were worries that other extensions would want some other
        failure mode than "silent truncation" when such limits are
        reached.  I'd like to comment that the limit only concerns
        storing a value, ie. is restricted to the action SET and the
        implicit storage of match variables from tests.  Sieve currently
        has no specified limit to the static length of string or
        multi-line, and it's unclear to me whether a conformant
        implementation is allowed to impose such limits.

non-security objections:

        Love Åstrand thinks restricting variable names to the English
        alphabet is a real problem.

        Jeffrey Hutzelman thinks a mechanism for quoting characters with
        special meaning in regex should be available.  this could be a
        modifier for SET, e.g. :quoteregex.

        Jeffrey Hutzelman thinks the text regarding interaction with
        regex should be in whichever of variables or regex is published
        last, so that what is a normative reference isn't mislabeled as
        informative.
-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 01 Jun 2005 17:10:41 +0100

>        alphabet is a real problem.  
Our discussion left me with impression that this is not an issue.

---

From: Ned Freed <[email-masked]>
Date: Wed, 01 Jun 2005 09:04:43 -0700 (PDT)

>         aspects of this behaviour needs to be documented.

Well, the obvious security issue here is that a script that pulls data out of a
header and then tests it may be able to be bypassed by putting a bunch of
leading material in the header so truncation occurs and the test fails. This is
something of a stretch, however, given that most such tests can be bypassed
simply by omitting the data being tested for entirely.

I'm curious what other supposed security issues there are with truncation. I'm
also skeptical that this is as big a mountain as they seem to think - sure
seems more like a molehill to me.

>         an
        
Alternative to what? In order for such information to be useful a script has to
be able to employ it meaningfully. So I find that there's an implementation
limit of foo. What do I do now? Code around it? If the limit can be coded
around without too much trouble why not code it that way for better portability
in the first place? Finding another implementation with a larger limit is
rarely an option... this really doesn't seem to accomplish much.

The only case I can imagine where this might be useful is when I know in
advance the length of the data I'm dealing with and want to check and see if it
can be processed. But the minimum maximums seem sufficient to cover this case,
so I'm left with this "alternative" in fact being no solution to any useful
problem.

It seems to me the useful alternative would be to have a way of testing to see
if truncation has occured. This way you could code tests to see if the
dataa being processed is abnormally large and respond accordingly.

But even this is of extremely marginal utility, for two reasons. First, string
sizes can already be checked, and it probably makes more sense to see if
something is abnormally long rather than checking to see if it has bumped up
against a truncation limit. Second, the availability of such a mechanism does
not mean it will actually be used, and my guess is that any such feature (and
this includes the namespace stuff) will see little if any actual use. And
rarely used features are security risks in and of themselves.

>         alphabet is a real problem.

Funny, it doesn't seem to have exactly been a showstopper in a truly vast
number of programming languages. Absent specifics as to why this is a real
problem, IMO this should simply be ignored.

>         modifier for SET, e.g. :quoteregex.

This, OTOH, is IMO a good idea, although we need :quotematches more than we
need :quoteregex. I support adding this to the variables extension.
Implementation is only a few lines of code, and it can and will be used.

>         last, so that what is a normative reference isn't mislabeled as

I guess I have no problem with this, but then again I personally find a lot of
the tension and angst over reference classification to be overdone.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 1 Jun 2005 15:52:15 -0400

>         modifier for SET, e.g. :quoteregex.

Agreed (and with :quotematches as Ned noted later); I've run into this
issue myself.

mm