The thing is that I think that my idea with custom checker is better, since, it provides more flexibility, to configure it even stricter, for different use cases.
For what I know, the current risks that exist in a exim configuration when using user-supplied data is:
- Email redirection (fooling Exim into sending email as a open SMTP) - requires a "safe" localpart - and in some cases a safe "remote part"
- Writing outside intended locations
- Reading outside intended locations
- SQL injection
- Command injection in system commands
- Export to Web browser/HTML
Etc.
By making a custom possibility, with a select predefined "guranteed safe string sets", it will make exim more secure.
I think we should avoid creating lots of filter functions, when the filter could be specified using one of the predetemited filters, or a custom charset.
One example that would be useful for me would be like
${untaint(${localpart},"0123456789")
For my Email-to-SMS gateway.
Note that today its pretty complicated to filter data as "you want" - you need to write a regexp and do search/replace. It would be much better if a general filter/untaint function could be implemented, so it become easy-as-ass to filter data - as I said, even in situations where you don't need untainted data, but still want to filter to make data safe.
-----Ursprungligt meddelande-----
Från: Heiko Schlittermann via Exim-users <exim-users@???>
Skickat: den 10 november 2020 22:44
Till: exim-users@???
Ämne: Re: [exim] tainted data issues
Hi,
I welcome the suggestions, especially the idea about gradually enabling taintchecks, to allow a smooth transition, as suggested by Mike Tubby.
taint_mode = yes | no | warn
Another idea from my side (it's similar to Sebastian N's idea)
> begin transports
> smtp:
> driver = smtp
> dkim_domain = $sender_address_domain
> dkim_selector = 2020-08-25
> dkim_private_key =
> /etc/exim/dkim/$dkim_selector.$dkim_domain.pem
We could provide taint checks for different situations, as the risk of using tainted data depends on the usage of the data (filename, log message, lookup key, …)
Provide a new set of functions:
${XXX{<string1>}{<string2>}{<string3>}}
${XXX{<string1>}{<string2>}fail}
${XXX{<string1>}{<string2>}}
With XXX as
- file (no "/")
- path (no "..")
- line (no "\r", "\n")
...
dkim_private_key = /etc/exim/dkim/${file{$dkim_selector.$dkim_domain.pem}}
or
dkim_private_key = ${path{/etc/exim/dkim/$dkim_selector.$dkim_domain.pem}}
This can give us flexibility where the current lookup based way of untainting doesn't work.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE -
