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 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/
