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@exim.org> 
Skickat: den 10 november 2020 22:44
Till: exim-users@exim.org
Ä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 -

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Reply via email to