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
