[grsec] Future of PAX_CONFIG_FORTIFY_SOURCE

Brad Spengler spender at grsecurity.net
Tue Sep 8 18:20:13 EDT 2009


> Could you shed some light on the status of PAX_CONFIG_FORTIFY_SOURCE
> development? Any chances for it to be included in the grsecurity patch
> any time soon?

As can be gleaned from the filename I chose for the patch in my home 
directory, I was underwhelmed with the coverage of a fully-implemented 
FORTIFY_SOURCE solution for the kernel.  The plan had been to see if 
FORTIFY_SOURCE could cover ~70-80% of the string/memory copying routines 
in the kernel, and then we would use the recent USERCOPY feature and 
apply it to the same functions when the compiler detected it could do 
nothing for the copy routine.

I documented a 30% coverage for the functions FORTIFY_SOURCE is meant to 
protect, nowhere near our goal (making the possibility of using USERCOPY 
for the remainder not feasible for performance reasons).  This included 
marking every possible kernel memory allocator with the appropriate 
attributes to notify gcc of the size of memory returned.  In general, 
from what I inspected from disassembling a large number of files, 
FORTIFY_SOURCE wasn't really protecting anything of worth -- that is, 
most of that 30% was copies of constant lengths into fixed-length 
buffers, not the kinds of memory copies that are actually exploitable.  
I did catch two or three overflows detectable at compile-time that were 
unexploitable and reported those to the respective authors.

During my investigation of FORTIFY_SOURCE, I noticed part of the reason 
for the extremely poor coverage of the kernel was that it didn't support 
determining the size of arrays within structures, of which there are 
many in the kernel.  I reported this to Jakub Jelinek, with an obvious 
example of the problem, and he called my report "useless."  So useless, 
in fact, that the very next day he committed the following code to gcc:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00419.html
So a side-effect of my investigation is that FORTIFY_SOURCE will be a 
little less useless in the future, once that patch gets out to gcc 
versions in wide-use (and used for compiling distributions).  Apparently 
no-one had bothered to look into this previously (no surprise to me).

I wasn't aware until several months later that Jakub had committed this 
patch a day after I notified him of the problem, so I went about solving 
it on my own (albeit with a more hackish solution for testing purposes).  
With the changes to support these arrays within structures, coverage 
improved by 33% compared to what FORTIFY_SOURCE was covering before -- 
it was now 40%, still nowhere near our goal, and still missing coverage 
of copies that would actually be exploitable.  So I gave up on the 
experiment, didn't bother uploading my updated patch, and moved onto 
more fruitful endeavors (like fixing up hundreds of function pointer 
tables within the kernel so they gained protection under KERNEXEC).

Hope that answers everything ;)

-Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://grsecurity.net/pipermail/grsecurity/attachments/20090908/0d22075e/attachment.pgp 


More information about the grsecurity mailing list