Well, this has been big news thanks to the slashdot effect. As far as I can tell, GCC is by default (-O2 and above, and possible -Os) enabling this optimization algorithm.
You can get the details on the exploit here: http://threatpost.com/blogs/researcher-uses-new-linux-kernel-flaw-bypass-selinux-other-protections (detailed here: http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1310528,00.html#) You can get a small gcc explanation here: http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Optimize-Options.html They seem to leave out an important concept of which I am unsure of if it is being handled or not. Threading, parallel programming, SMP, etc.. Simply because in a linear application the NULL check wouldn't be needed based on the described logic does not mean that a non-linear program will have not freed the pointer at any point between dereferencing and checking to see if it is still allocated. This would be a pain in the but to check and confirm for every single application out there so I am suggesting removing it from the default options as a security measure. I am not entirely sure how to do this, so I browsed around in the gcc-4.4 code and did the following: diff -r -u gcc-4.4.0.orig/gcc/opts.c gcc-4.4.0/gcc/opts.c --- gcc-4.4.0.orig/gcc/opts.c 2009-07-18 15:11:04 -0500 +++ gcc-4.4.0/gcc/opts.c 2009-07-18 15:19:37 -0500 @@ -898,7 +898,7 @@ flag_regmove = opt2; flag_strict_aliasing = opt2; flag_strict_overflow = opt2; - flag_delete_null_pointer_checks = opt2; + flag_delete_null_pointer_checks = FALSE; flag_reorder_blocks = opt2; flag_reorder_functions = opt2; flag_tree_vrp = opt2; In the code, opt2 is defined as: opt2 = (optimize >= 2); So I assume that settings this to FALSE would have the desired effect. (I have no clue about -Os and how to handle that one) I am no gcc expert however, please confirm this for me if anyone knows any better. The downside is that the expected behavior is to have the optimization enabled, but this is a from scratch system afterall. Tweaking the default system code at the compile level feels right to me. The other alternative I can think of is by adding in the -fno-delete-null-pointer-checks into the gcc specs file such that it gets passed before each and every program in the same manner as the gcc-4.1.2 SSP patches were applied. If the passing the -fno-delete-null-pointer-checks is an easier and better way please tell me, I just do not remember how that works. Furthermore, for flags like -pthread, the -fno-delete-null-pointer-checks should be passed along with it. I can see some sort of specs file adjustment going on with pthread. -- Kevin Day -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
