I agree about this, but a more simpler interface would be a multiuse
interface that suits most usages of user-supplied data.
And that is to give a very simple "filter" interface that will filter out
all invalid characters and also untaint the data.
Like:
${filter{$data_to_be_filtered}{<permitted_characters>}}
<permitted_characters> is NOT expanded, meaning only character that needs to
be escaped in that circumstance is { and }.
Example:
${filter{$phonenumber}{0123456789}}
Would simply strip all characters except 0-9 from $phonenumber and return in
untainted form, so if $phonenumber contains "hey0do56" then
${filter{$phonenumber}{0123456789}} will return 056
Of course, the function ${filter must then be built in such a way its 100%
safe to use, basically theres nothing a untrusted user could do to cause
${filter to return any character outside of the administrator-configured
filter list.
Of course you could supply a "unsafe" list of characters, but thats the
system administrator's responsibility.
So instead of separate functions check_file_path or check_sql_data etc, its
better to have one function, that can be administrator-configured to allow
arbitary filtering, which also could be used in other situations where you
want to filter user-supplied data from unwanted characters, even for
functions that do allow tainted data.
And the best with such ${filter function is that it will never throw any
exceptions or fail, it will just filter out whatever danger is supplied. Of
course, if admin wants it to throw exception in case of unpermitted
characters, its easy for system administrator to do a string compare before
and after the filter function, and err out if they don't match (meaning,
something got filtered out).
And in the rare cases you want to filter out certain character sequences,
its easy to, before the filter function, do a sg{} and replace all unwanted
sequences with a character outside the permitted space, and then run the
filter function.
-----Ursprungligt meddelande-----
Från: Evgeniy Berdnikov via Exim-users <exim-users@???>
Skickat: den 26 juni 2020 23:12
Till: exim-users@???
Ämne: Re: [exim] de-tainting
Hello.
On Thu, Jun 25, 2020 at 09:16:59PM +0100, Jeremy Harris via Exim-users
wrote:
> On 25/06/2020 20:50, Evgeniy Berdnikov via Exim-users wrote:
> > at least in statement "In all other situations, this variable
> > expands to nothing", because it may be filled if no lookup is done.
>
> Yes, that is no longer true. See the sections starting
>
> http://exim.org/exim-html-current/doc/html/spec_html/ch-domain_host_ad
> dress_and_local_part_lists.html#SECTlistresults
Referenced text have broken record about 'domains' match, I expect some
words about $domain_data variable. Hope you'll supply them.
And I have question about user interface, which becomes very obscure and
inconvenient. All these innovations with tainting bring problems. In some
cases they may be "resolved" by lookups. Obviously, the idea is to restrict
file name patterns to some predefined set of strings, stored somewhere in
database, in hope that this set would be less risky then data from the
wild. Well, it seems good on first glance. But many users want to use file
system as native database with data-driven records, i.e. with file names
constructed from $local_part, $domain, $sender_host and other variables
that can't be predicted. They can't be expressed as a set of predefined
strings. Is there any effective solution for this case?
I can propose awful "untainting" algorithm: 1. construct a tainted string,
2. put it into database, 3. make lookup to get back "untainted"
data. Any protection against "../" inside, or against SQL injection will
be dropped, but it allows construction of arbitrary untainted strings with
minimum efforts. And I'm sure that samples of such "untainting functions"
became available in internet if Exim's interface continue to evolve in
direction of obscurity and inconveniece.
In my opinion, in order to give an effective tool for data protection, one
should supply simple and copletely "intuitive" interface. For files it may
be a function, say, ${check_file_path:...}, which checks its argument for
dangerous patterns (such as "../") and specials, then returns untainted
copy of string if everything is OK, or throws an exception.
For SQL such function may be ${check_sql_data:...}. Moreover, it seems
better to add such functionality to existing quoting functions:
${qoute_ldap:...}, ${quote_mysql:...}, etc.
Jeremy, I kindly propose to think about movement in this direction.
You have done a really great work, but for the present its result is too
complex and too restrictive for use. If you don't supply simple and
convenient interface, Exim would lose its main advantage, power of built-in
scripting language, and inavitably lose its users. IMHO.
--
Eugene Berdnikov
--
## 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/
