> Yes, $domain will be tainted. Using it as part of the
> conditions in a lookup is still permitted; the taint-tracking
> is not intended to stop that (because it is in general a useful
> facility).
Now I am seriously surprised! Exim key lookups are parsed along with
expansions, so expansions cannot insert braces and confuse the parser,
which makes that approach safe. But that does not apply to query
expressions, which are parsed by the lookup, not by the string parser,
after the string parser is done.
You saw how the query expression was used in an unsafe way that is
exploitable by tainted data, so the problem is real.
I agree I never thought about this when taint-tracking was introduced,
but the current state is a serious security problem to me, and one I
somehow expected to be solved by taint-tracking.
> Yes, for the ldap lookup here, quoting should be done.
I agree. The question is how to proceed on this. One approach would
be calling a lookup parser instead of passing it a string after
expansion. That would limit how dynamic queries may be and it would mix
Exim and query syntax, requiring callbacks from the lookup parser to the
exim string parser--quite complicated. Another approach would be to have
e.g. quote_ldap detainting the quoted string if called inside a ldap
lookup, which would be unexpected semantics, but it avoids the syntax mix.
Right now tainted data can be exploited in query style lookups, which
is surprising if you believe taint-tracking protects you from that. I
have no satisfying solution to that, unfortunately.
Michael
