Re: [exim] string expansion

Top Page
Delete this message
Reply to this message
Author: Phil Pennock
Date:  
To: Uwe Rothmeier, exim-users
Subject: Re: [exim] string expansion
On 2017-05-26 at 16:27 -0400, Phil Pennock wrote:
> On 2017-05-26 at 13:13 +0200, Uwe Rothmeier wrote:
> > condition = ${if or{{match_address{$local_part@$domain}{lsearch;CONFDIR/ldapdir}} \
> >             {match_local_part{$local_part}{lsearch;/etc/exim4/aliases/$domain}}}{1}{0}}

> >
> > Works with Exim 4.72
> >
> >
> > With Exim 4.89 $domain ist not expanded:
> > failed to open /etc/exim4/aliases/$domain for linear search: No such file or directory
>
> To use the config unmodified, rebuild Exim with EXPAND_LISTMATCH_RHS
> defined. This was a change in Exim 4.77 for security, because many
> people had security vulnerabilities in their configurations.
>
> This is called out in "README.UPDATING", which should be read before
> updating. Exim 4.77 was released in October 2011.


The condition:

match_local_part{$local_part}{lsearch;/etc/exim4/aliases/$domain}

is probably a close match to:

bool{${lookup{$local_part}lsearch{/etc/exim4/aliases/$domain}{yes}{no}}}

This has the advantage of _only_ looking at $domain as something for
constructing a path component, so as long as it comes after something
which validates that $domain is "real" (and not something like
"../../../etc/passwd"), you're safe. Your particular use, based upon
$domain, was pretty safe before too.

Unfortunately, people used stuff like $h_from: as a key, which suddenly
means that you get SQL injection attacks. We played whack-a-mole with
explaining that people had insecure configurations and mostly got
ignored. So we made a security-motivated compatibility-breaking change
so that the default was harder to make insecure.

-Phil