> We understand that this introduces an additional level of complexity
> for the configuration. And we're seeking for better ways, to balance
> between a secure and a simple configuration.
>
> We're open for suggestions. And intentionally we do not provide
> suggestions from our side here and now (this doesn't mean that we do
> not have ideas ;)) My thoughts I'll present here later.
Here are some suggestions, ranging from moderate to radical.
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.)
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. Many system
administrators have existing Exim configurations that likely have
tainting problems, and we have no assurance that we can find them all
in advance of a live deployment. Live deployment with tainting creating
hard failures is a serious land mine and problem.
(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.)
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). That would be potentially somewhat safer than
running with the 'just always produce warnings and no more' option, but
might invite people to use this option permanently instead of upgrading
their configuration.
Semi-radical: provide an ACL, router, and transport modifier that
checks some variable or content for dangerous contents (possibly in
several variations), and either passes it or triggers a condition
failure or deferral. Possibly this should be implemented as a function
that can be used in 'condition = ...' and '${if ...}' clauses, but if so
care should be taken to allow for a 'defer' result, not just pass/fail.
This would provide more assurances to sysadmins who are writing more
dynamic configurations that they haven't let something slip through in
their process for de-tainting variables through database queries or
whatever.
People will inevitably wind up wanting to check various pieces of data
for 'bad stuff' and then de-taint them if there isn't any (or reject
them if there is), so the only question is whether Exim will provide
an official best effort at this (one that can be evolved over time
and perhaps have options for what sort of dangerous thing should be
accepted), or whether it will leave people writing configuration files
on their own to write hundreds of different and likely inferior and
flawed versions.
(Frankly, we would probably use it early in our ACLs too even though
we have hard-coded lists of valid recipients and so on, just so that
we can log messages if some attacker is trying to feed us dangerous
stuff.)
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.
Radical: in ACLs, verifying the receiver or sender address through
'verify = <whatever>' should optionally un-taint $local_part, $domain,
and so on. This should be controlled through a new option that has to
be turned on. In many configurations, verifying at least recipient
addresses will automatically restrict them to a list of known good
domains, local parts, and so on. Forcing ACLs to additionally re-verify
domains and local parts to have untainted variables is one part
make-work and one part duplication of knowledge of valid addresses. I
would much rather prefer it if there was only one section of my Exim
configurations that knew (and had to know) how to verify all local
parts, for example, rather than two sections that I am now required to
keep in sync or suffer from subtle issues.
Radical: provide an ACL and/or router modifier that immediately
un-taints $local_part, $domain, and so on (perhaps specified variables
or all variables). This would let us assert that yes, even though
Exim cannot recognize it, we are confident that our configuration has
verified and restricted these variables to safe value (possibly through
use of the 'check for dangerous content' addition proposed above).
The advantage of providing a clear marker for where this is happening
is that you can then look for and audit these places. People *will*
figure out clever ways of de-tainting variables without doing anything
else to them, so the only question is whether Exim will make it easy
to find the places where this is being done or will leave sysadmins
and other parties to try to find them through reverse engineering what
various weird incantations do.
(Is this mathematical pure security? No. But real security is about
usability. Mathematically pure security that people bypass in practice
is not useful security.)
- cks
