This was patched in 0.3.2 but will explicitly mention it in the next release.

The preliminary patch has a major flaw: it does not reap any of the child processes it creates, resulting in a new zombie sendmail process for each call to popenv(). This eventually results in resource starvation and the milter rejecting emails due to being unable to fork or create a new thread.

Ref:
http://bugzilla.redhat.com/583523
http://bugs.debian.org/575019

I have attached a revised patch to Bug #29326 that adds an additional parameter to popenv() to return the PID of the child process, enabling the caller to use waitpid() when closing the pipe and avoid the zombie processes. This patch is based on the one from Bjørn Mork in the Debian bug report.

when this bug gets fixed , there should be a release update
to make clear that this got fixed, also other patches
i.e. smtp auth should be included too then

Patch looks reasonable, but needs a function prototype adding for popenv() above where it's called in main().

I had to hack my initscript a bit to get the milter to run as root so that I could test out -u -x (-x only works if the milter runs as root). I also had to tweak the sample exploit slightly to get it past sendmail, which rejects the "|" exploit with a "Cannot mail directly to programs" error. And finally, I had to turn off SELinux enforcing mode to be able to write to /tmp, which would otherwise be blocked by SELinux policy, at least in current Fedora releases.

Instead of:
rcpt to: root+:"|touch /tmp/foo"

I used:
rcpt to: root+" ; touch /tmp/foo ; echo "

Without the patch, this created /tmp/foo; with the patch, it didn't. Normal mail delivery is working fine but I'm still awaiting a spam mail to check that the spambucket still works (going home now so will report back later).

The use of popen() for the spambucket case isn't a problem though, is it, since it's not passing user-supplied input through the shell - only the admin-supplied spambucket address?

I like the popenv() approach though.

There was a remarkably similar issue with clamav in 2007 (CVE-2007-4560). I've had a go at writing a patch based on the clamav code (which is GPL version 2 or later, like spamass-milter) but have not had time to test it today.

I'll have a go at testing it tomorrow if nobody else has had time to do so in the meantime.

(file #19901)

Version(s): 0.3.1; possibly earlier versions
Description:   A vulnerability was reported in SpamAssassin Milter Plugin. A remote user can execute arbitrary code on the target system.

When the software is invoked with the expand (-x) flag, the software makes an unsafe popen() call. A remote user can send a specially crafted RCPT TO value to execute arbitrary code on the target system. The code will run with the privileges of the target service.

look
http://securitytracker.com/id?1023691