Re: [exim] [taint] $local_part in require files

Top Page
Delete this message
Reply to this message
Author: Andreas Metzler
Date:  
To: exim-users
Subject: Re: [exim] [taint] $local_part in require files
On 2020-05-01 Jeremy Harris via Exim-users <exim-users@???> wrote:
> On 01/05/2020 07:01, Andreas Metzler via Exim-users wrote:

[...]
> >
> > "require_files = $local_part_verified:$home/.procmailrc"
> >
> > for consistency's sake. (To get in the right mindset and avoid using
> > "$local_part" for filename, commands or user specification.)


> Yes, I think it should. I'll make that change.
> Thanks for the careful reading.


Somehow related, I have stumbled upon this paragraph in 
26.1 The file and directory options [of the appendfile transport]
-------------------------------------------------
Tainted data may not be used for a file or directory name. This means
that, for instance, $local_part cannot be used directly as a component
of a path. It can however be used as the key for a lookup which returns
a path (or component).
[...]
file = ${if eq{$address_file}{inbox} \
            {/var/mail/$local_part} \
            {${if eq{${substr_0_1:$address_file}}{/} \
                  {$address_file} \
                  {$home/mail/$address_file} \
            }} \
       }
-------------------------------------------------


Clearly in this example $local_part *is* used unmodified as a component
of a path (in the inbox branch). I have not tested the exact usecase but
I think this would fail *if* $local_part was tainted since $if does not
un-taint (rightfully so), e.g. this fails with tainted $local_part:
writetofile:
driver = appendfile
file = ${if eq {1}{1} {/var/mail/$local_part} {blah}}

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'