Author: Michael Haardt Date: To: exim-users Subject: Re: [exim] 4.94 - De-tainting without lookup?
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.
Tainted variables are not an obstacle meant to enforce workarounds
somehow.
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.
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.