The 2020-06-29 19:54:26, Michael Haardt via Exim-users wrote:
> Matthias Hörmann <matthias.hoermann@???> wrote:
>
> > Why not use a simple whitelist string replacement? All characters but
> > some known valid characters (say [a-zA-Z0-9_.-]) are replaced with a
> > known valid character (say _)? We use that in puppet all the time to
> > generate paths. As long as you disallow slashes you don't even have to
> > worry about .. appearing in there. Potentially a check for a maximum
> > length might be useful to add but that should fail on its own if the
> > filesystem can not handle it.
>
> For your application, that may suffice. For others, more may be needed.
> Thinking of /base/$variable/path, it may be quite important that the
> variable is not "..", especially if you create files and directories
> on demand.
But the solution I propose is strictly more powerful than just allowing
lookups to detaint values. In fact it is lookups that may suffice for
some simplistic cases but won't work anywhere else while a sanitizing
option should work for all use-cases, even if the results might
sometimes be visually less than pleasing (e.g. a string consisting
entirely of replacement characters).
>
> Tainted variables are not an obstacle meant to enforce workarounds
> somehow.
By releasing them without any warning that is exactly what you are
forcing onto people though. You made the exim config language severely
less expressive and people are not just going to throw away their
use-cases that can not be implemented with lookups.
Worse, you might make some people pin exim to an old version and forget
about upgrading it which is worse in a security sense.
>
> The idea is to verify tainted values and assign the result to an untainted
> variable that is further used like previously tainted variables were, ideally
> doing so only once at a central spot. The verifier decides if the passed
> value is valid.
>
> The problem of tainted values possibly exploiting something due to a
> missing verification is real.
It is, I have seen it in the wild on our servers...which is why we have
been using character whitelists in our ACLs for quite a while now,
throwing out all that nonsense that the spec for email addresses allows
but nobody uses in practice, e.g. {}
>
> String manipulations as such can't be verifiers, but they can sanitize bad
> values, so they pass a subsequent verifier, if that's what you want to do.
>
> As I wrote, currently there are only lookups acting as verifier and that's
> likely not enough. If you want to sanitize values, you could translate
> some characters to an underscore (still tainted), feed that to a path
> component "lookup" that makes sure it is not ".", ".." and contains no
> slashs, get an untainted value from that and be fine. Except that we
> don't have a pseudo lookup like that yet, and that there may be better
> ideas how to integrate verifiers that check conditions other than a key
> or query lookup in a database of some kind.
But your lookups are _not_ verifiers. They are a de-tainting mechanism
that only works for a rather limited set of use-cases, namely the ones
where you have a very limited set of known valid values. We are talking
about email here though, we can not use lookups for the entire set of
valid local parts and domains on the internet, not even the subset we
wish to receive mail from or send mail to.
>
> Michael
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
--
Mit freundlichen Grüßen,
Matthias Hörmann
fon: +49 (0) 521 - 329647-29
fax: +49 (0) 521 - 329647-40
email: matthias.hoermann@???
---------------
saltation GmbH & Co. KG | Niederwall 43 | 33602 Bielefeld
Sitz Bielefeld | Amtsgericht Bielefeld HRA 15344
Persönlich haftende Gesellschafterin:
saltation Beteiligungs-GmbH | Niederwall 43 | 33602 Bielefeld
Sitz Bielefeld | Amtsgericht Bielefeld HRB 39339
Geschäftsführer: Daniel Brün
---------------
Wir erfüllen unsere Informationspflichten gem. Artt. 13-14 DS-GVO
durch Veröffentlichung auf unserer Internetseite unter
https://www.saltation.com/de/datenschutzerklaerung.html
oder durch Zusendung auf Ihre formlose Anfrage.
