Folks,
For those living in a cave the past few days: problems in how bash
parses environment variables during startup, before executing the code
it is given to run, mean that anyone who can completely control an
environment variable given to bash can cause arbitrary shell code
execution.
Exim does not, by default, use a shell for executing commands; however,
the `use_shell` option on a Pipe Transport can be set, to cause /bin/sh
to be used to run the command. If /bin/sh is bash, then you have
problems.
Further, a mail delivery agent such as procmail might invoke a shell to
run external commands, and environment variables set by Exim are likely
to still be set by the time the intermediate processes use a shell.
To quote from
<
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-security_considerations.html#SECTsecconslocalcmds>:
> There are a number of ways in which an administrator can configure
> Exim to run commands based upon received, untrustworthy, data.
> Further, in some configurations a user who can control a .forward file
> can also arrange to run commands. Configuration to check includes, but
> is not limited to:
>
> Use of use_shell in the pipe transport: various forms of shell command
> injection may be possible with this option present. It is dangerous and
> should be used only with considerable caution. Consider constraints
> which whitelist allowed characters in a variable which is to be used in
> a pipe transport that has use_shell enabled.
Alas, even this warning is not sufficient; a number of environment
variables are set by Exim when invoking a command for a Pipe Transport;
these are described at:
<
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_pipe_transport.html#SECTpipeenv>
A few of these are both under attacker control and likely to be settable
to something malicious which won't interfere in the mail reaching a pipe
transport. `SENDER`, `LOCAL_PART_SUFFIX` or `LOCAL_PART_PREFIX` and in
unusual environments perhaps `LOCAL_PART` or even `RECIPIENT` will be
controllable to this extent. Further, the `environment` command might
be used to set arbitrary variables, and anything which sets a value
based on the received message is likely suspect.
An email address can contain a selection of characters on the left-hand
side of the "@" sign which might surprise those who haven't read the
specifications. Hint: almost anything goes.
If you are running Exim on a system where `/bin/sh` is Bash _and_ you
either have a Pipe Transport which has `use_shell` set or you invoke
commands which might themselves invoke a shell, then:
(1) Please upgrade bash to a fixed version;
(2) See if you can temporarily disable the relevant handler address
until such time as you can get bash updated;
(3) See if you can set /bin/sh to a simpler shell, designed for
scripting only (Debian and derivatives tend to use Dash);
(4) Investigate your RCPT ACLs to see if allowed character constraints
will help in your setup; but if your environment is such that you
can't just deploy a fixed Bash now, then you likely have sufficient
complexity that emergency splicing new constraints into allowed
addresses will result in chaos and nightmares and you're better off
focusing on updating the shell instead.
The RCPT ACL only helps if such restrictions also apply to the
verification path used for `verify = sender`.
Longer term, moving away from `use_shell` may help, as will taking time
to perform a proper assessment of what characters should be allowed in
email addresses and then carefully crafting RCPT ACLs to conform. Be
wary though of what controls you try to add on email addresses used as
senders from domains not under your administrative control.
- -Phil
