> On Mon, Aug 29, 2011 at 4:57 PM, Corey Henderson <corman at cormander.com> > wrote: >>> You can avoid a lot of the problems by making sure >>> that apache can't write anywhere that is mounted with execute >>> capability. >>> >> >> Or install a security module to do that for you. One that I've written >> that is nearing the end of its beta: >> >> https://github.com/cormander/tpe-lkm >> >> In some cases, you can even tell it to let apache not exec anything at >> all, if you're not running cgi scripts or bytecode php deployments >> (zend, >> etc). >> > > Would it have blocked this widely known/used vulnerability? > http://seclists.org/fulldisclosure/2010/Oct/257 > Yes, because you've created the file you're executing: $ gcc -w -fPIC -shared -o /tmp/exploit payload.c $ ls -l /tmp/exploit -rwxrwx--- 1 taviso taviso 4.2K Oct 15 09:22 /tmp/exploit* # Now force the link in /proc to load $ORIGIN via LD_AUDIT. $ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3 The attempt fails as designed by tpe. I've specifically tested this one. It also stops the trick of using ld-x.x.so to execute binaries, because mmap and mprotect are also checked in addition to execve. Tested on both CentOS 5 & 6. Haven't bothered testing it on 4 since it's close to EOL. -- Corey