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>
