Re: [exim] tainted data issues

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 -