Re: [exim] tainted data issues

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Michael Haardt
Date:  
À: Jeremy Harris via Exim-users
Sujet: Re: [exim] tainted data issues
Jeremy Harris via Exim-users <exim-users@???> wrote:

> > Radical: $local_part, $domain, and similar tainted variables should
> > be automatically un-tainted once they pass a check that would generate
> > the untainted version of the variable.


> On the other side of the coin, re-using the same variables and
> changing the taint-status of the content makes problem-discovery
> harder. When you do run into a taint issue, under the "same variables"
> approach, it is not immediately obvious from the config file source
> that you forgot to de-taint the value.


The problem is that right now it is not obvious which variables are
tainted, there are no *_data variables for all tainted variables and
there is no generic mechanism to verify a tainted variable.

> > Radical: in ACLs, verifying the receiver or sender address through
> > 'verify = <whatever>' should optionally un-taint $local_part, $domain,
> > and so on.
>
> Considerably more complex in its security aspects; more than I want
> to think about at this time. Maybe one for the future.


From the little experience so far it shows that verification of tainted
variables is logically tied to routers. A central ACL does not
match that structure.

Domains and local_parts are checked very early in the router and I
believe verifying variables early in the router is the right place.

The problem is that the variable verification side effect is neither
obvious nor universal usable for all variables, and I am not
sure we need copies of all variables that are tainted.

> > Radical: provide an ACL and/or router modifier that immediately
> > un-taints $local_part,
>
> No. As responded to elsewhere: providing an overly-obvious way
> to game the security means no security.


To me, half way there would be right: Add a new option for routers that
is checked before all other options and verifies variables, detainting
them instead of copying them. The actual verification using a lookup
is fine to me. It was already shown how to use lookups against regular
expressions, no need to make it easier than that.

To avoid confusion, as verification has its own meaning in Exim, it
could be called validation:

validate_local_part_suffix = ${lookup {$local_part_suffix} ....}

That way it is obvious which variables are valid and which are not,
validation stays pretty much where it is now and it is clear that in
order to use a variable at a critical place, it must be validated first.
No hidden side effect.

Like local_parts/domains right now, only generic, without creating a
copy of the variable and applicable to all tainted variables.

It would be cool if we had something that validates all variables used
as the key of the lookup for query lookups, again allowing single query
lookups that make use of local part, domain and possibly other variables.
The current need to duplicate lookups makes configurations less clear
than they could be.

Michael