grsecurity 4.11 Updates
July 14, 2017
Today we announce the latest release of grsecurity for version 4.11.10 of the Linux kernel. The focus for this release has been to eliminate boilerplate code/annotations by making certain compiler plugins smarter. This was the first step necessary for a smart and maintainable implementation of KERNSEAL, the long-awaited PaX feature designed to deal with the remaining exploit vector of data-only attacks. These improvements not only eliminated a significant amount of code that otherwise needed to be manually maintained, but identified a large number of new hardening opportunities that it was able to apply automatically. During an audit of the code undertaken due to recent GCC 8 developments, a few important issues were resolved. The significant improvements to one of the plugins uncovered an interaction with RANDSTRUCT which was also resolved. Numerous other hardening improvements were made that will be discussed in detail at a later time.
Recently, upstream developers have included several changes/fixes from our older patches into the latest Linux kernel version 4.12, and we commend their work by highlighting some of those features here.
We continue to offer the same high level of ASLR entropy on PowerPC as we have since we first implemented ASLR on PowerPC in 2003. The work at the time was performed on a 200MHz Power Mac G3 and later on a 64-bit Power Mac G5. Upstream now includes a toggle which allows entropy to be administratively configured to similar levels.
We continue to make LSM structures read-only as we did initially 7 years ago in 2010. Many thanks to Kees Cook for crediting us for this that same year here as I believe I was the first to overwrite security_ops to disable SELinux and other LSMs back when I released the first public NULL pointer dereference exploit for Linux in 2007. The technique was further refined and placed in my "enlightenment" exploit framework. Unlike upstream, however, our implementation works regardless of CONFIG_SECURITY_SELINUX_DISABLE being enabled, as it is on Ubuntu and other distributions. We encourage upstream to look into this, as it was overlooked in their blog post.
We continue to carry our fix from 10 years ago in 2007 when SSP was first introduced to the kernel, which fixed the stack canary size on 64-bit systems. This was pointed out to the upstream maintainer for SSP in 2008 here and unfortunately ignored in the 9 years since. We are happy to see that this long-standing fix of ours has been upstreamed.
Since upstream developers are trying to create a fix for the stack clash vulnerability that does not break userland, we encourage them to take a look at our 2010 fix for the issue that does not break userland in any of the ways upstream is now concerned about. We pointed out the Java incompatibility directly to Linus in 2011 and are happy to see action now being taken to address the issue.
We continue to maintain, as mentioned in our 2013 blog post, that KASLR is cargo cult security that offers nothing more than a false sense of security. Upstream has instead enabled it by default on x86. We encourage them to provide to the public their strategy for dealing with the numerous generic attacks that exist against KASLR so that it can provide useful security. While their effort to relocate the GDT to a read-only area makes sense in the context of KASLR, it is not equivalent to the read-only GDT provided by PaX in KERNEXEC since 2003, as it still leaves a globally-writable map of the GDT behind.
Our 4.12 port is underway and nearly complete. Part of this involved adapting to the advertised usercopy consolidation. Since one of our goals with grsecurity is for the code to be maintainable across Linux versions, we avoid making these kinds of sweeping changes across the tree that would be subject to constant additional upstream churn. Nevertheless, this upstream consolidation is a welcome improvement that we've improved even more: 1 file changed, 91 insertions(+), 85 deletions(-)
Please watch this space for more updates, and we welcome any feedback.
-Brad