I've just posted an article about my work on porting PaX's KERNEXEC and UDEREF features to ARMv6+ and implementing KERNEXEC on ARM LPAE with PXN support. This work solidifies grsecurity's place as offering the most security for any Linux usage: server, desktop, or mobile/embedded. I've fully removed writable and executable memory from the kernel and disabled the kernel's ability to accidentally or maliciously access userland memory directly for any purpose. This provides numerous kernel self-protection benefits in line with other features of PaX and grsecurity and significantly raises the bar for reliable kernel exploitation.
Read the full post here
Today the PaX Team published a blog post on Intel's recent addition to the Intel Architecture: Supervisor Mode Access Prevention (SMAP). Keeping with the industry standard of copying PaX features years after the fact and failing to provide credit, Intel's SMAP aims to provide similar protection as PaX's 6-year-old UDEREF feature. The PaX Team's post describes the operation of SMAP, how it differs from Ivy Bridge's SMEP, and how PaX will make use of SMAP in the future to improve UDEREF performance on amd64.
Read the full post here.
Today Emese Revfy published a blog post about her continuing work on a gcc plugin that aims to eliminate vulnerabilities stemming from truncated or over/underflowing size arguments to allocators and their wrapper functions. The plugin has been available in grsecurity for some time now through its inclusion in PaX. The posting covers the gcc fundamentals involved in the plugin, a walkthrough of the effects of the plugin on gcc's intermediate representation, and some pitfalls discovered during its development. Read on here for the full post.
The PaX Team and Brad Spengler will be presenting at the "Hackers to Hackers Conference" (H2HC) in Sao Paulo, Brazil on October 20th-21st, 2012.
In his talk entitled "The Case For Grsecurity", Brad will provide a justification for the existence of grsecurity, document some representative failures of upstream Linux security, explain the motivations and goals of the project, discuss some recently-developed features, illustrate the "Scorched Earth" style of vulnerability and exploit response from the grsecurity and PaX projects, and hint at future enhancements.
The PaX Team, in his talk entitled "PaX: the untold story (kernel self protection)", will be presenting on an area of PaX that has received little attention both in the security community and in academia, despite it being the main focus of both grsecurity and PaX for the past many years: kernel self-protection. If you want to be informed on the cutting edge of security research and learn what the future holds in this area, you won't want to miss this talk.
Today the PaX Team presented on "20 Years of PaX" as the keynote speaker at the highly regarded SSTIC conference in France, which is this year celebrating its own 10th anniversary. The PaX Team's presentation, as its name implies, covers the history, current feature-set, and future plans and visions for the PaX project. Find out what's in store for the future of compiler-assisted security and virtualization by reading his presentation slides.
Discovered by Kostya Kortchinsky and published on his blog with further reporting by ars technica, Microsoft has been found to be running a large number of Skype supernodes on Linux servers hardened with grsecurity. Though Microsoft is not a sponsor of grsecurity, this news serves as demonstration of a large-scale grsecurity deployment.
The PaX Team and I have decided on Linux 3.2 as the new stable kernel, joining with the choice made by Debian and Ubuntu. We will continue to support 2.6.32 until the end of this year, at least.
Today we've released our first test patch for Linux 3.0.3. If you've been following recent changes to the patch, you'll have noticed the two new GCC plugins bundled with the patch as part of PaX. Currently, users of GCC 4.5 and above (the versions of GCC that support plugins) will be able to improve the security of the recent PAX_STACKLEAK feature (see the blog for more details) and automatically place large numbers of previously-writable tables of function pointers into read-only memory.
The plugins, written by Emese Revfy and the PaX Team, are pioneering a new method in system protection -- with more additions forthcoming. Be on the lookout for a blog post describing the details behind these new plugins.
In case you haven't been following recent grsec developments, I've set up separate RSS feeds for the stable and test patches. They're available at http://grsecurity.net/stable_rss.php and http://grsecurity.net/testing_rss.php.
Full changelogs for the stable and test trees are now available as well at http://grsecurity.net/changelog-stable.txt and http://grsecurity.net/changelog-test.txt.
SSL is also now supported on the main website and forums.
The main obvious thing that concerns us with these long-term stable kernels is the backporting of security fixes, given the continued attempts to fix vulnerabilities silently in only the latest kernels. We'll be sure to keep watch of the situation as we've been doing for some time now and point out vulnerability fixes we spot that need to be backported.
Hopefully this will provide more opportunities for organizations seeking more stability and less unpredictability in their kernel upgrades to be able to take advantage of the benefits of using grsecurity.
We will of course continue to follow the latest kernel releases in addition to this long-term stable kernel support.
One of the things I've been working on recently has been documenting the various aspects of grsecurity, including the RBAC system. I've built off the great Wikibook a grsecurity user, Meev0, spent a great deal of time creating. The Wikibook is available at: http://en.wikibooks.org/wiki/Grsecurity. Contained in the Wiki is notes on proper bug reports, extensive listings of RBAC features, explanations of policy syntax, policy writing suggestions, how to use the learning mode, etc. I encourage everyone to contribute to the Wiki in areas where the content is currently lacking.
Most recently, the PaX Team and I have been able to improve on some work we did several years ago -- porting grsecurity/PaX features to a number of different architectures. With sponsorship returning to normal levels, I've been able to purchase hardware for some architectures we supported fully some years ago (but haven't been able to since because the machines died). I've replaced a dead PowerMAC G3 (ppc32) with a PowerMAC G5 (ppc64). I've also been able to acquire a recent ARM development board, so expect to see grsecurity and PaX coming to your cell phone or other embedded devices soon (MIPS-based embedded devices too as soon as I'm able to obtain a suitable development board). The grsecurity webserver (currently a 333mhz sparc64 server) will be upgraded shortly as well.
So far, with the new hardware and a couple days of extensive work, we have:
- Fixed PAGEEXEC support in 2.6 kernels on sparc32/sparc64/ppc32/ppc64
- Updated EMUPLT to support recent versions of glibc (this is a non-x86 feature)
- Added USERCOPY (a feature I developed that I'll discuss below) to sparc32/sparc64/ppc32/ppc64
- Added REFCOUNT to sparc64 (thanks to twiz for his great help with this)
- Added NOELFRELOCS support to ppc64
- Removed mmap_min_addr for the sparc architecture, as it's unnecessary (the sparc architecture catches invalid userland accesses, unlike some other architectures) and can break applications if configured improperly
Aside from non-x86 improvements to our projects, we've also created a number of important new features and changed others:
- PAX_USERCOPY: this feature I developed (which was improved and added within PaX) performs bounds checking on kernel objects, when copying into or out of them via userland. The feature provides the most protection for objects located on the heap (the feature supports all current allocators: SLAB, SLUB, and SLOB, with the strictest checks existing for SLUB). For objects located on the stack, the bounds checking is less strict -- mainly to prevent infoleaking of the entire kernel's memory space. The bounds checking on stack objects will improve in future versions of the feature.
- Prevention of some integer overflows involving kernel allocators: (e.g. "kmalloc(sizeof(somestruct) * attacker_controlled_len), GFP_KERNEL);") This feature that I developed (which is enabled by default with no configuration option) covers all the kernel allocators which accept a size as an argument, failing the allocation and logging the attempt upon detection of an integer overflow.
- Harden module auto-loading: By learning from the recent exploits that generally involved causing an unused module to be loaded into the kernel that was then exploited, I developed GRKERNSEC_MODHARDEN. It prevents non-root users from causing modules to be auto-loaded into the kernel. The option shouldn't cause any incompatibilities (and any incompatibilities are easily fixed): a desktop edition of Fedora Core 11 can be booted fully without a non-root user attempting to auto-load a module.
- Automated required steps for GRKERNSEC_HIDESYM: The documentation for GRKERNSEC_HIDESYM has always mentioned restricting access to kernel image paths, as they can be abused by an attacker to determine targets for exploits just as /proc/kallsyms can be used. By enabling GRKERNSEC_HIDESYM, non-root users will automatically be prevented from reading kernel images/modules in /boot, /lib/modules, and the kernel source tree currently being built from.
- Improved signal logging: the name of the signal being forced on a process is reported instead of the signal number (easier to read for inexperienced users). It will also now report the address that caused the signal to be forced on every architecture.
- GRKERNSEC_HARDEN_PTRACE: this feature was pulled from a feature that has existed for years within the RBAC system, just adapted for use outside of the RBAC system. It prevents non-root users from ptracing arbitrary processes that they own. The point of this is to defeat ptrace-based process/tty sniffers/monitors floating around in the wild that steal keystrokes and SSH/GPG passwords. At the same time, it still allows the most common legitimate uses of ptrace, such as strace ./binary or gdb ./binary. strace -p and gdb -p won't be able to be used with this option, except as a root user.
- GRKERNSEC_BLACKHOLE: The stealth netfilter module has been removed and replaced with a much easier to use feature that performs the same task, ignores blackholing for the loopback interface, and has much better performance. This feature is used to reduce the effectiveness of certain types of DoS attacks.
- Hundreds of function pointer tables in the kernel have been made read-only (protected by KERNEXEC). I've developed a script that will find and fix the markings on tables of vm_operations_struct, file_operations, inode_operations, dentry_operations, seq_operations, address_space_operations, and more.
- FORTIFY_SOURCE was evaluated for use in the kernel, but demonstrated poor performance (30% coverage when utilizing it fully and properly marking allocators -- 40% after some internal modifications). Based on my analysis, it wasn't protecting useful areas of the kernel (only trivial unexploitable cases), so its inclusion was scrapped. As a result of this work however, I reported a weakness to Red Hat about the inability of __builtin_object_size (which FORTIFY_SOURCE uses) to determine the size of arrays within structures. A fix for this issue will eventually make it out to the compilers vendors ship, improving userland security for everyone.
- The x64 vsyscall page and its shadow page have been made both read-only and non-executable, preventing the interrupt->process context exploit technique used in sgrakkyu's published SCTP remote exploit.
- copy_to/from_user was hardened on the x86, x64, sparc32, sparc64, ppc32, ppc64, arm, s390, and ia64 architectures.
- PAX_MEMORY_UDEREF now will co-exist with VMware guests using HW-assisted virtualization
- KERNEXEC now supports VMWare's VMI paravirtualization
- A kernel with PAX_MEMORY_UDEREF support built in can be used on different machines with different virtualization/paravirtualization configurations through the use of a kernel command-line option
- Additional analysis was added to gradm to detect poorly configured policies
- ip_override: Overriding INADDR_ANY for subjects in the RBAC system was added, to force all programs within a given chroot to use a specific IP, for instance.
I've also expanded the Research section of the website, where we list academic papers referencing grsecurity or PaX. The current count is 152!
I've surely left out some other minor changes to the code, but the above should be a good general summary of what we've been up to lately. As always, if you're interested in sponsoring further work of this type (we have some really great things in the pipeline), email me at firstname.lastname@example.org.
I've also made some improvements to the website. I've consolidated the download links, improved the test patch page (added a button to subscribe to the test patch RSS feed), and created a new section for support which describes the different ways to get help with grsecurity.
In addition to this, I've created two new links on the side -- "Books" and "Research". The "Books" section provides links to security books that mention grsecurity. Buying these books helps support grsecurity. The "Research" section includes links to PDFs (or abstracts if no PDF was available) for all academic research papers I've been able to find that discuss grsecurity or PaX. If you know of, or are the author of, any academic paper which is missing from my list, please let me know.
- Binutils 2.18 is required for this release, as older versions are incompatible with PaX. This requirement is enforced at build time.
- PaX, even when completely disabled, is incompatible with a VirtualBox/VMWare host (it can still be used on a guest OS). The source of the incompatibility is not yet known.
- ATI binary video drivers trigger the UDEREF protection. Whether an exploitable scenario exists within the driver has not been determined.
Due to the current economic situation, grsecurity recently lost its primary sponsor. After discussing the situation for some time with the PaX team, I have come to two scenarios for the future of the project. If within the next few months I can find one or more sponsors to get the project back to its previous level of sponsorship, I'll continue development on the project and keep up to date with the latest kernels as I've done in the past. If I am unable to find anyone interested in sponsoring the project, development and availability of the software will end on March 31st. Further public development of PaX will be uncertain.
Sponsoring grsecurity has many benefits:
- I will personally respond to any support requests (you can call me if you wish)
- You are able to make feature requests to improve the usefulness of grsecurity to your organization
Some examples of RBAC features written through this offer included hostname support, invertedsocket policies, virtual interface support, and PAM authentication support
- Upon request, I will review your RBAC policy and report vulnerabilities or make suggestions
- A logo and a link to your organization will be listed on the sponsors page
- Helping continue a project with a circle of influence far outside its own userbase
To illustrate this last point, we've put together a graph that shows how grsecurity and PaX have influenced security system implementations in nearly every mainstream operating system. Over the past eight years of our existence, we have not only managed to stay relevant to the current state of an ever-evolving industry, but have advanced the state of the art and provided real security based on results and not what was most commercially profitable. The graph is available here.
I'd like to thank all sponsors of grsecurity, past and present, for their help in continuing an important project.
To discuss possible sponsorship, please contact me at email@example.com.
- Many bugfixes, including fixes for RBAC auditing and RBAC policy recreation from renaming.
- Relaxed restrictions for the 'd' subject flag in the RBAC system -- a task may now access its own /proc/<pid>/fd and mem entries.
- Forced compiler errors on mistaken PaX configuration (such as enabling PAX_NOEXEC but not enabling SEGMEXEC nor PAGEEXEC).
- Extended username limits in the RBAC system
- Improved policy verification and base policy enforcement
- Added support for new capabilities added in Linux 2.6
- Updated default policy and learning configuration
- Corrected policy support on files larger than 2gb prior to the RBAC system being enabled
- An update to the latest version of PaX which includes numerous bugfixes
Due to Linux kernel developers continuing to silently fix exploitable bugs (in particular, trivially exploitable NULL ptr dereference bugs continue to be fixed without any mention of their security implications) we continue to suggest that the 2.6 kernels be avoided if possible.
It is not clear if the PaX Team will be able to continue supporting future versions of the 2.6 kernels, given their rapid rate of release and the incredible amount of work that goes into porting such a low-level enhancement to the kernel (especially now in view of the reworking of the i386/x86-64 trees). It may be necessary that grsecurity instead track the Ubuntu LTS kernel so that users can have a stable kernel with up-to-date security fixes. I will update this page when a final decision has been reached.
In the meantime, please email firstname.lastname@example.org and let him know how much you appreciate the hard work he has put in for the past 8 years. The accomplishments of the PaX Team have extended far beyond just Linux, and have today found their way into all mainstream operating systems.
We are erring on the side of caution and calling this bug exploitable, though we believe reliable exploitation of the bug (in the privilege escalation sense, not the DoS sense) to be very difficult, especially in the presence of KERNEXEC/UDEREF.
Using the RBAC system's PaX flag support to enforce system-wide MPROTECT enabling could have prevented triggering of the bug, since it requires the creation of an executable stack to trigger the vma mirroring bug.
- Fixes to PaX flag support in RBAC system
- PaX updates for non-x86 architectures in 2.4.34 patch
- Fix for setpgid in chroot problem reported on forums
- Removal of randomized PIDs feature, since it provides no useful additional security and wastes memory with the 2.6 kernel's pid bitmap
- Fixed /proc usage in a chroot in 2.6 patch
- Added admin role to generated policy from full learning
- Resync of PaX code in 2.4 patch