-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Folks,
Until fairly recently, the Dovecot documentation proposed an Exim
configuration sample which resulted in insecure Exim configurations.
We're told that there are now automated exploits available for at least
one common exploit framework.
If you have configured Exim to work with Dovecot, it's good to check
that you're up-to-date with their recommended configuration. If you
haven't, but grep'ing your Exim configure file shows the presence of
"use_shell", then now is a good time to review.
$ fgrep use_shell -- $(exim -bP configure_file)
It's unfortunate that we're in a situation where even mail experts who
work on another mail product can so inadvertently create a security
problem.
Exim's original author (Philip Hazel) deliberately made sure that Exim
does not use the shell by default, so that arbitrary content in a
sender's address can not be injected for shell parsing. This work on
his part was explicitly to protect against this kind of attack.
Alas, while the use_shell documentation warned of the issues, the
Security Considerations section of the documentation did not reference
this, so folks may not have caught the full implications during any
security review of their configurations.
We have since updated the documentation for the next release of Exim to
include a "Running local commands" section in the "Security
considerations" chapter, referencing this and other items of concern.
I have included a rendering of this to plain text below, for your
convenience.
The use_shell option, while dangerous, does have legitimate uses and we
can't remove the facility. It remains something that does have to be
explicitly enabled in configuration and the default behaviour of Exim
does protect against this kind of attack.
PLEASE: review your configurations, in light of the points below, to
better protect yourselves.
Thank you for your attention,
- -Phil Pennock, pp The Exim Maintainers.
Advisory:
https://www.redteam-pentesting.de/de/advisories/rt-sa-2013-001/-exim-with-dovecot-typical-misconfiguration-leads-to-remote-command-execution
New documentation; commit:
http://git.exim.org/exim.git/commitdiff/5336c0d9bbf5de9a948c168de692a092e557d8b6
As plain text:
- ----------------------------8< cut here >8------------------------------
54.5 Running local commands
- ---------------------------
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.
* A number of options such as forbid_filter_run, forbid_filter_perl,
forbid_filter_dlfunc and so forth which restrict facilities available to
.forward files in a redirect router. If Exim is running on a central mail
hub to which ordinary users do not have shell access, but home directories
are NFS mounted (for instance) then administrators should review the list
of these forbid options available, and should bear in mind that the options
that may need forbidding can change as new features are added between
releases.
* The ${run...} expansion item does not use a shell by default, but
administrators can configure use of /bin/sh as part of the command. Such
invocations should be viewed with prejudicial suspicion.
* Administrators who use embedded Perl are advised to explore how Perl's
taint checking might apply to their usage.
* Use of ${expand...} is somewhat analagous to shell's eval builtin and
administrators are well advised to view its use with suspicion, in case
(for instance) it allows a local-part to contain embedded Exim directives.
* Use of ${match_local_part...} and friends becomes more dangerous if Exim
was built with EXPAND_LISTMATCH_RHS defined: the second string in each can
reference arbitrary lists and files, rather than just being a list of
opaque strings. The EXPAND_LISTMATCH_RHS option was added and set false by
default because of real-world security vulnerabilities caused by its use
with untrustworthy data injected in, for SQL injection attacks. Consider
the use of the inlisti expansion condition instead.
- ----------------------------8< cut here >8------------------------------
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAlG2T+8ACgkQQDBDFTkDY38kqgCghOb32WUEUP8212kAzANaWtFv
RvIAn292Yfv7ch9b0YQL3ehbiw2y7pr4
=p/uS
-----END PGP SIGNATURE-----
--
## List details at https://lists.exim.org/mailman/listinfo/exim-announce Exim details at http://www.exim.org/ ##
Hash: RIPEMD160
Folks,
Until fairly recently, the Dovecot documentation proposed an Exim
configuration sample which resulted in insecure Exim configurations.
We're told that there are now automated exploits available for at least
one common exploit framework.
If you have configured Exim to work with Dovecot, it's good to check
that you're up-to-date with their recommended configuration. If you
haven't, but grep'ing your Exim configure file shows the presence of
"use_shell", then now is a good time to review.
$ fgrep use_shell -- $(exim -bP configure_file)
It's unfortunate that we're in a situation where even mail experts who
work on another mail product can so inadvertently create a security
problem.
Exim's original author (Philip Hazel) deliberately made sure that Exim
does not use the shell by default, so that arbitrary content in a
sender's address can not be injected for shell parsing. This work on
his part was explicitly to protect against this kind of attack.
Alas, while the use_shell documentation warned of the issues, the
Security Considerations section of the documentation did not reference
this, so folks may not have caught the full implications during any
security review of their configurations.
We have since updated the documentation for the next release of Exim to
include a "Running local commands" section in the "Security
considerations" chapter, referencing this and other items of concern.
I have included a rendering of this to plain text below, for your
convenience.
The use_shell option, while dangerous, does have legitimate uses and we
can't remove the facility. It remains something that does have to be
explicitly enabled in configuration and the default behaviour of Exim
does protect against this kind of attack.
PLEASE: review your configurations, in light of the points below, to
better protect yourselves.
Thank you for your attention,
- -Phil Pennock, pp The Exim Maintainers.
Advisory:
https://www.redteam-pentesting.de/de/advisories/rt-sa-2013-001/-exim-with-dovecot-typical-misconfiguration-leads-to-remote-command-execution
New documentation; commit:
http://git.exim.org/exim.git/commitdiff/5336c0d9bbf5de9a948c168de692a092e557d8b6
As plain text:
- ----------------------------8< cut here >8------------------------------
54.5 Running local commands
- ---------------------------
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.
* A number of options such as forbid_filter_run, forbid_filter_perl,
forbid_filter_dlfunc and so forth which restrict facilities available to
.forward files in a redirect router. If Exim is running on a central mail
hub to which ordinary users do not have shell access, but home directories
are NFS mounted (for instance) then administrators should review the list
of these forbid options available, and should bear in mind that the options
that may need forbidding can change as new features are added between
releases.
* The ${run...} expansion item does not use a shell by default, but
administrators can configure use of /bin/sh as part of the command. Such
invocations should be viewed with prejudicial suspicion.
* Administrators who use embedded Perl are advised to explore how Perl's
taint checking might apply to their usage.
* Use of ${expand...} is somewhat analagous to shell's eval builtin and
administrators are well advised to view its use with suspicion, in case
(for instance) it allows a local-part to contain embedded Exim directives.
* Use of ${match_local_part...} and friends becomes more dangerous if Exim
was built with EXPAND_LISTMATCH_RHS defined: the second string in each can
reference arbitrary lists and files, rather than just being a list of
opaque strings. The EXPAND_LISTMATCH_RHS option was added and set false by
default because of real-world security vulnerabilities caused by its use
with untrustworthy data injected in, for SQL injection attacks. Consider
the use of the inlisti expansion condition instead.
- ----------------------------8< cut here >8------------------------------
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAlG2T+8ACgkQQDBDFTkDY38kqgCghOb32WUEUP8212kAzANaWtFv
RvIAn292Yfv7ch9b0YQL3ehbiw2y7pr4
=p/uS
-----END PGP SIGNATURE-----
--
## List details at https://lists.exim.org/mailman/listinfo/exim-announce Exim details at http://www.exim.org/ ##