Re: [exim] Exim 4.94.0.4 works where Exim 4.94 fails with ta…

Góra strony
Delete this message
Reply to this message
Autor: Mike Tubby
Data:  
Dla: exim-users
Temat: Re: [exim] Exim 4.94.0.4 works where Exim 4.94 fails with tainted path 'not permitted'


On 07/11/2020 23:30, Michael Haardt via Exim-users wrote:
>> Ok, have had a 5 minute scan read ... seems that tainted data is a
>> {potential} problem, but in my case the variables that I use to build a
>> path in transport 'local_delivery':
>> [...]
>> have already been used as keys in a database look-up previously in the
>> router that cause the transport to be called:
> That's not how things work. The variable will stay tainted even when
> looked up.


Agreed - but see below.

>
>> Can we have, instead, a directive that allows us to assert 'untainted'
>> over one or more variables:
> Previously, a single lookup that checked both local part and domain to
> let the router match was popular. Now that's fighting against the design.
>
> Use two lookups, one for local_parts and one for domains, even if both
> perform the same lookup, to set $local_part_data and $domain_data as
> side effect, and things are easy from there. It's a new way of thinking
> about routers: You do not just need a condition to let the router match
> the address, you also need to set the *_data variables as side effect.
>
> You can work around the *_data variables, but it will make everything
> complicated.
>
> Just untainting variables without verification is a bad idea.


Agreed, but in my case they are verified (see below)

>    One could
> argue if there shouldn't be a verifier option for variables instead of
> setting the *_data copies, so a single lookup could verify und untaint
> two variables, but some check is required.  Before I used generic
> conditions to verify variables and another condition to match the router,
> now I use local_parts and domains, which I never did before.  It is about
> as readable, once you get used to it.


I get the purpose of tainted data and preventing its use, however if you
look at my router:

#
# Normal local delivery
#
local_delivery:
        driver = accept
        condition = ${lookup mysql{SELECT
CONCAT(users.username,'@',domains.domain) AS email FROM \
                users LEFT JOIN domains ON users.domain_id=domains.id
WHERE \
                users.username='${quote_mysql:$local_part}' AND \
                domains.domain='${quote_mysql:$domain}' AND \
                users.active=1 AND \
                domains.active=1}{yes}{no}}
        transport = local_delivery
        user = mail
        group = mail

when the condition checks my work email address (mike.tubby@???):

    users.username == mike.tubby
    domains.domain == thorcom.co.uk

and it has to be a perfect match, character for character, hence my
assertion is that transport = local_delivery is only ever called if the
condition is true and for the condition to be true $local_part and
$domain have matched what is in my database and are therefore 'verified'
safe.  Well this is true for my use case, at least.

Now it looks like I have to use additional look-ups, perhaps something
like this:

    $domain_data = ${lookup mysql{SELECT domains.domain AS domain FROM \
                users LEFT JOIN domains ON users.domain_id=domains.id
WHERE \
                users.username='${quote_mysql:$local_part}' AND \
                domains.domain='${quote_mysql:$domain}' AND \
                users.active=1 AND \
                domains.active=1}}

    $local_part_data = ${lookup mysql{SELECT users.username AS username
FROM \
                users LEFT JOIN domains ON users.domain_id=domains.id
WHERE \
                users.username='${quote_mysql:$local_part}' AND \
                domains.domain='${quote_mysql:$domain}' AND \
                users.active=1 AND \
                domains.active=1}}

to simply send my 'already known good' keys $local_part and $domain
round in circles and get the duplicate data (same values) from the
database rather than use them, directly?


Mike


> Michael
>