Security researcher called "Kingcope" pointed out: [1] http://lists.grok.org.uk/pipermail/full-disclosure/2010-March/073489.html a deficiency in the way Mail Filter plugin for the SpamAssassin spam filter sanitized certain mail header field, when spamass-milter was run with the expand flag (-x option). If a remote attacker sent email message with certain, specially-crafted mail header field, and this message was subsequently processed by the SpamAssassin Mail Filter plugin, it could lead to arbitrary code execution with the privileges of the privileged system user (root). Preliminary upstream patch: [2] http://savannah.nongnu.org/support/download.php?file_id=19902 References: [3] http://secunia.com/advisories/38840/ [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573228 CVE Request: [5] http://www.openwall.com/lists/oss-security/2010/03/10/2
This issue affects the versions of the spamass-milter package, as shipped with Fedora releases of 11 and 12, and as shipped within EPEL4 and EPEL5 repositories. Please fix once upstream patch for this deficiency is available.
This issue is mitigated somewhat in the Fedora/EPEL packages by the facts that (a) the milter runs as its own UID, "sa-milt", and (b) the problematic "-x" option is not the default configuration. Since the last change in upstream CVS was in July 2006, I'll work on a patch myself and attach it to the upstream bug report: http://savannah.nongnu.org/bugs/?29136 I'll also consult with the debian maintainer.
Paul, just to be clear, 'mitigated somewhat' means that the normal configuration is immune to the associated attack because '-x' is not used?
Yes, that's right. In fact, for -x to be used, the milter would have to run as root because it uses "sendmail -bv" to expand aliases, and that only works when run as root. The current initscript for spamass-milter runs the milter as account "sa-milt" and would have to be hacked to enable it to run as root (I will add a facility to do this, with an appropriate warning, in the next release). Furthermore, users running with SELinux enabled would have only limited exposure because the milter is confined and cannot for instance write to /tmp. It's probably limited to writing to /var/{lib,run}/spamass-milter in fact.
Created attachment 401011 [details] Local copy of preliminary upstream patch Paul is currently testing
spamass-milter-0.3.1-17.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-17.fc13
spamass-milter-0.3.1-17.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-17.fc12
spamass-milter-0.3.1-17.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-17.fc11
spamass-milter-0.3.1-17.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-17.el5
spamass-milter-0.3.1-17.el4 has been submitted as an update for Fedora EPEL 4. http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-17.el4
*** Bug 577401 has been marked as a duplicate of this bug. ***
spamass-milter-0.3.1-18.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report.
spamass-milter-0.3.1-18.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
spamass-milter-0.3.1-18.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
spamass-milter-0.3.1-18.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
spamass-milter-0.3.1-18.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
This issue is now resolved in all supported Fedora and EPEL releases, by spamass-milter-0.3.1-18.*. The fix is based on upstream's proposed patch from https://savannah.nongnu.org/bugs/?29136 but this patch has not been committed to upstream CVS, let alone become part of a new upstream release. However, I have tested it quite extensively myself and it is also included in Debian's update for this issue. The removal of the use of popen() in spamass-milter means that the SELinux policy for the milter can be tightened: in particular, these policy rules are no longer needed and I shall suggest their removal from Fedora policy on the Fedora selinux list. corecmd_exec_shell(spamass_milter_t) corecmd_search_bin(spamass_milter_t) This change might not be acceptable upstream until spamass-milter upstream has released an update that removes use of popen().