January 10th, 2011

execstack on the rampage.

Currently in Fedora 14 execstack avc's seem to be popping up all over the place.

As Uli Drepper describes:
execstack

As the name suggests, this error is raised if a program tries to make its stack (or parts thereof) executable with an mprotect call. This should never, ever be necessary. Stack memory is not executable on most OSes these days and this won't change. Executable stack memory is one of the biggest security problems. An execstack error might in fact be most likely raised by malicious code.

See my overview of security features in Fedora and RHEL for more information, specifically appendix A. It explains how to avoid executable stacks.

What exactly caused this, I am not sure.  We have been telling people to search for libraries marked with the execstack flag. 

# find /lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X
# find /usr/lib -exec execstack -q {} \; -print 2> /dev/null | grep ^X
or
# find /lib64 -exec execstack -q {} \; -print 2> /dev/null | grep ^X
# find /usr/lib64 -exec execstack -q {} \; -print 2> /dev/null | grep ^X
If you find one, you can turn off the execstack flag using:

/usr/bin/execstack -c BADLIB.so.  

Now you can try the application again and make sure everything continues to work.  In most cases the app will work fine and the execstack avc will be eliminated.

John Reiser comments in the bugzilla that if you build a library that is asking for execstack you can fix it:

The package maintainer can turn off execstack when linking the app by  
adding "-Wl,-z,noexecstack" to the LDFLAGS (or CFLAGS) in the Makefile. 
This takes precedence over .o files or libraries that request execstack, 
either deliberately or because some .S assembly language file forgot to 
use ".section .note.GNU-stack,"",@progbits" where the empty attribute  
string "" turns off execstack.

Finally there has been some indication that the culprit has been libxvidcore...
execstack -c /usr/lib/libxvidcore.so*