On 10/11/2020 19:45, Chris Siebenmann via Exim-users wrote:
Moderate: there should be a full chapter in the Exim documentation on
tainting and how to deal with it. This should cover the security risks
that it's there to deal with, common configuration snippets that are now
a problem, and how to deal with tainting and de-tainting data in common
configuration needs. Right now there is not even an explicit subsection
for tainting in the Security Considerations chapter.
(If in the process of writing this chapter things are difficult to
explain or the configuration changes seem awkward, well, that is a
sign of where improvements are needed.)
The problem I had in writing documentation was in the opposite
direction: Exim's taint-tracking is a very simple concept and
does not take many words to describe. Nor does the ethos of
de-taint methods.
It didn't take anything near a chapter. Please see the current
(post-4.94 release) state of the documentation, posted at
https://people.exim.org/jeremy.harris/docs/HEAD/exim-html-4.94-RC999/exim-html-current/doc/html/spec_html/
Semi-radical: there should be a configuration file option that turns
taint errors into warnings that do not stop processing but that are
merely logged to the main log or perhaps also the paniclog.
As noted elsewhere, possible though expensive in developer time.
(It would be nice if all system administrators had automated test
suites that completely cover their entire Exim configuration. If people
think that having such a test suite should be required for reliable
Exim version upgrades, perhaps someone should write a chapter for the
Exim documentation on how to create and operate it, and also how to
measure the configuration file coverage so that you know you have 100%
coverage.)
"Someone" needs to volunteer, obviously.
An optional but nice extra would be a third choice for this option,
which generates 'this would have been rejected' warnings if the contents
of the tainted variable being used seem harmless, but force hard errors
if it appears to have dangerous contents (whatever the Exim developers
consider that to be).
More complexity is bad. Asking developers to think harder probably
also isn't good.
Semi-radical: provide an ACL, router, and transport modifier that
checks some variable or content for dangerous contents
We have that. All data provided by an untrusted source, described
as "tainted" for a shorthand.
(possibly in
several variations),
No, complexity again.
Radical: $local_part, $domain, and similar tainted variables should
be automatically un-tainted once they pass a check that would generate
the untainted version of the variable. Forcing system administrators
to switch which variable they use has two problems. First, it is
make-work, since the two variables are essentially bolted together
(and if they are not, it is likely to surprise people, for example if
you somehow get $local_part changed but $local_part_data stays with
an old value). Second, it is part of what makes it impossible to have
a configuration file that works in both an old un-tainted Exim and
a new tainting Exim, since $local_part_data does not exist in older
Exims. Forcing configuration file updates at the same time as Exim
version updates complicates sysadmin life.
On the other side of the coin, re-using the same variables and
changing the taint-status of the content makes problem-discovery
harder. When you do run into a taint issue, under the "same variables"
approach, it is not immediately obvious from the config file source
that you forgot to de-taint the value.
This one is open to more opinions. I chose the "different variables"
approach
Radical: in ACLs, verifying the receiver or sender address through
'verify = <whatever>' should optionally un-taint $local_part, $domain,
and so on.
Considerably more complex in its security aspects; more than I want
to think about at this time. Maybe one for the future.
Radical: provide an ACL and/or router modifier that immediately
un-taints $local_part,
No. As responded to elsewhere: providing an overly-obvious way
to game the security means no security.
--
Cheers,
Jeremy
--
## 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/
