Thats up to the system administrator to configure.
Thats why I propose that it should be possible to specify non-ascii characters like \xXX to allow UTF8 characters to be specfied. Thus system administrators can configure this based on locality, so those in sweden would accept åäöÅÄÖ as recipient and so on.
Thats why I suggest it to be custom, so system administrators in different countries can configure it differently.
As I said, this untaint/filter method could be provided in ADDITION to whatever exist, so it won't break anything.
-----Ursprungligt meddelande-----
Från: Mark Elkins via Exim-users <exim-users@???>
Skickat: den 12 november 2020 07:31
Till: 'Mailing List' <exim-users@???>
Ämne: Re: [exim] tainted data issues
One could do this for a punycode version of the domain name but the address part before an '@' can be UTF8 - such as "café". Please don't break any internationalised addresses (Universal Acceptance and all that). I'm wondering if an inverse check could be done, as in look for anything bad? (e.g. Double dots and slashes)
On 2020/11/10 22:45, Sebastian Nielsen via Exim-users wrote:
> I think as I said, provide a untaint tool, that allows custom data to
> verify against.
>
> Like:
> ${untaint(${var},
> "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789")}
>
> Regardless of if ${var} is tained or not, the result of ${untaint} is
> always untainted.
>
> The character string, is then what to filter against - all characters
> not on that particular list, will be removed from ${var} silently
> before passing it on.
>
> This allows system administrators, to do entirely custom checks
> against dangerous data, since in all cases where tainted data becomes
> a security issue, is when delimiter characters is inserted in the text
> to escape out of the enviroment that the command or whatever is
> executed in, and be able to execute arbitary commands or write in arbitary locations.
>
> Its very important that the function itself is "safe" - meaning it
> should not be possible in ANY way for tainted data to "leak through"
> the filter, ergo it must not be possible for any character not on
> administrator's list, to end up in the return of the untaint function.
>
> Also the filter list itself, must also be done in such a way variable
> expansion never happens in the filter list - only way to specify a
> filter list, is to manually specify it in config file.
>
>
> This gives most flexibility, and also encourages security by making it
> easy to filter data before passing it on, making it a "habit" for
> system administrators.
> Then it will be a habit to always ${untaint} even in cases where
> untainted data is not required, incresing security even further.
>
> In the above example, if ${var} contains
> "Sebastian/Users/file@???" the result of the untaint
> operation with that particular filter list would be "SebastianUsersfilesomewherecom"
> which is a completely safe string to pass on to filesystem.
>
> To make it even easier for system administrators, make premade filter
> lists
> like:
> %%FILESYSTEM%% = Contains a list of characters that is safe for use in
> functions that read or write to filesystem.
> %%SYSTEM%% = Containst a list of charactes that is safe to pass on to
> a live terminal, like when running system commands or similiar.
> %%SQL%% = Contains a list of characters that is safe to pass on to a
> raw SQL prompt without rsik of injection.
> %%HTML%% = Contains a list of characters that is safe to output to a
> web browser without security risks.
> %%LOCALPART%% = Contains a list of characters safe in localpart of a
> email adress.
> %%HOSTPART%% = Contains a list of characters safe to use in a DNS name
> or host part of a adress including IP literals.
> %%FULLEMAIL%% = Contains a list of characters that is allowed and safe
> to use in a full email adress.
>
> So writing:
> ${untaint(${var}, "%%SQL%%")}
>
> Would filter ${var} in such a way that its safe to pass on to a raw
> SQL string without injection risk.
>
> Note that these %% strings is NOT string expansions - instead a
> customized system for specifying pre-made filters, preventing
> variables from being accidentially expanded and used in a filter list,
> which in itself is a big security risk, since then filter lists could be modifyed from the outside.
>
> However, \xXX should be expanded of course, so people can write
> characters that don't exist on the keyboard, in some cases they are useful.
>
>
> Such a untaint function should be easy to implement.
> And would make exim much more secure, as its a very easy function,
> making it a habit to use the function by system administrators.
>
> YES - it is possible to "shoot yourself in the foot" with the function
> by specofying characters that is unsafe for that particular usage, but
> then the responsibility is on the system administrator.
>
>
> Best regards, Sebastian Nielsen
>
> -----Ursprungligt meddelande-----
> Från: Michael Haardt via Exim-users<exim-users@???>
> Skickat: den 10 november 2020 20:16
> Till: Jeremy Harris via Exim-users<exim-users@???>
> Ämne: Re: [exim] tainted data issues
>
> Jeremy Harris via Exim-users<exim-users@???> wrote:
>> The one major hole I know of is for the creation of a mailbox file,
>> first time, for an account.
> After having reviewed a number of configurations, I am sure there is more.
>
> While I am not pleased with the design of verifying tainted data, or
> introducing it in such an invasive manner without a new major version,
> the need of doing so absolutely exists. That said, the current design
> is usable and it solves the problem. Using it may either convince us
> of being the best solution, or show which specific alternative is better.
>
> The ongoing configuration reviews certainly uncovered potential
> problems, so rolling back is not an option without a replacement for
> the current verification.
>
> Michael
>
> --
> ## List details athttps://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details athttp://www.exim.org/ ## Please use the Wiki with
> this list -http://wiki.exim.org/
>
>
--
Mark James ELKINS - Posix Systems - (South) Africa mje@??? Tel: +27.826010496 <tel:+27826010496> For fast, reliable, low cost Internet in ZA:
https://ftth.posix.co.za <
https://ftth.posix.co.za>
--
## 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/
