Home > News

New blog post on advances in kernel hardening on ARMv6+ (Feb 18 2013)

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

New blog post on SMAP, Intel's 6-year-late copy of PaX's UDEREF (Sep 7 2012)

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.

New blog post: "Inside the Size Overflow Plugin", by Emese Revfy (Aug 28 2012)

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.

Brad Spengler and PaX Team presenting at H2HC, Oct 20-21 in Brazil (Aug 28 2012)

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.

PaX Team keynote speaker at SSTIC 2012 (Jun 6 2012)

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.

Microsoft/Skype run grsecurity on 10,000 supernodes (May 1 2012)

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.

New blog post: "Recent Advances: How We Learn From Exploits" (Feb 15 2012)

It's been a while since the last blog post -- I was expecting a post from the PaX Team about their pioneering work in security-focused gcc plugins -- but with that still forthcoming, I decided to write a post of my own about some recent feature additions to grsecurity and the thought processes behind them. Read on here.

Linux 3.2 chosen as new stable kernel, 2.6.32 support continues (Feb 04 2012)

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.

First grsecurity test patch released for Linux 3.0 (Aug 23 2011)

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.

New blog, other updates (Jan 1 2011)

The PaX Team and I have decided to create a new blog where we will give our perspectives on security and other topics of interest. You can find it (and the first post) here: http://forums.grsecurity.net/viewforum.php?f=7.

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.

[08/10] Linux Security Summit 2010 slides published

I've updated the papers section of the site to include my slides from the Linux Security Summit 2010. The title of the presentation was "Linux Security in 10 Years". In the presentation, I demonstrated the threat of kernel exploitation, how kernel exploitation subverts access control/container-based security, the need to have a broader view of system protection, in particular the need for kernel self-protection.

[04/25] UDEREF implemented for x64

If you're not subscribed to the grsecurity mailing list, you missed out on the UDEREF/x64 announcement. The announcement, addressing benefits, limitations, and performance concerns, is available here for those who missed it.

[02/10] Official grsecurity/PaX support on ARM

With the stable patch of grsecurity released today, the PAGEEXEC, MPROTECT, and ASLR features of PaX have been implemented for the ARM architecture. Specifically, the PAGEEXEC functionality exists for v6 and v7 ARM CPUs. Our development machine for this work is the Gumstix Overo, utilizing the ARM Cortex-A8 3530 processor. The same processor type is found in the latest mobile/embedded devices, including the Apple iPhone 3GS, Palm Pre, and Motorola Droid. As time permits, additional architecture-specific protections will be added for this increasingly important platform.

[01/25] grsecurity is supporting a Linux 2.6.32 stable kernel

After some discussion and mutual agreement about future plans, the PaX Team and I are happy to announce that we plan on supporting the 2.6.32 kernel on a long term basis, as indeed a number of major distros will be basing their kernels off it.

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.

[09/27] Development/documentation update

The PaX Team and I have been rapidly developing new features for PaX and grsecurity for the past many months. Though many of the new features won't be news to those of you following the test releases (which I hope is most of you), I thought it would be good to provide a summary of what we've been working on recently.

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 spender@grsecurity.net.

[03/22] Website update

Grsecurity development continues: last week I added a feature to the RBAC system which provides functionality equivalent to a BSD jail feature, but with more fine-grained control. Within RBAC policies, you now have the ability to force a given subject to use a specified source IP address when it listens on a port or connects out of the machine.

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.

[12/27] New (final?) grsecurity release and important announcement

grsecurity 2.1.12 has been released for the 2.4.37 and 2.6.27.10 versions of the Linux kernel. Changes since 2.1.11 include numerous bugfixes to both grsecurity and PaX. Support for capabilities introduced in newer 2.6 kernels has been added to the RBAC system. A case where incorrect subject flags were used in policies generated from learning has been corrected. Handling of corner cases in vma mirroring has been improved. A new feature has been added to PaX in the 2.6 patch: PAX_REFCOUNT. This new feature prevents the exploitation of most reference count overflow vulnerabilities in the kernel. The feature exists for both 32 and 64-bit x86 platforms and is enabled in the medium and high security settings of grsecurity. Sanity checking has been added at build time for grsecurity to detect too-common misconfigurations of PaX we've seen mentioned on the forums. A kernel command line parameter, "pax_nouderef" has been added to selectively disable PaX's UDEREF feature at boot time.

Requirements/Known Issues:

• 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 spender@grsecurity.net.

[04/21] grsecurity 2.1.11 patches updated, 2.6.24.5 supported

The 2.6 patch has been updated to 2.6.24.5 and fixes a serious RBAC system flaw where user_transition_deny/allow rules were being ignored. Both the 2.4 and the 2.6 patches have been updated to fix the return values of sys_setfsuid and sys_setfsgid.

[04/17] grsecurity 2.1.11 patch for 2.6.24.4 updated

The 2.1.11 patch for Linux 2.6.24.4 has been updated to fix a deadlock scenario with setpgid() and CONFIG_GRKERNSEC_CHROOT_FINDPROC discovered during an internal audit.

[04/14] grsecurity 2.1.11 released for Linux 2.4.36.2/2.6.24.4

A new stable version of grsecurity has been released for the 2.4.36.2 and 2.6.24.4 versions of the Linux kernel. This release is a maintenance release (due to the work required in porting such a large patchset to each new 2.6 kernel as we have with the test patches), though we continue to welcome suggestions for additional features for grsecurity. Changes in this release include:

• 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 pageexec@freemail.hu 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.

[06/18] Note on PaX support for x86-64 kernels on Socket 478 Celeron D processors

The 64-bit Socket 478 Intel Celeron D processors lack NX support unlike other 64bit Intel/AMD chips. PaX currently only utilizes NX on 64bit kernels, but since the mentioned Celeron processors lack NX support, PaX's PAGEEXEC feature, though able to be selected in the kernel configuration, will not be active in the built kernel. Since the specific processor can only be detected at runtime, it's not possible to restrict the PAGEEXEC option in the kernel config. Owners of these CPUs are urged to build 32bit kernels and use SEGMEXEC to make full use of PaX with the smallest performance hit.

[01/22] Update on PaX expand_stack() vulnerability, updated patches

The recently updated grsecurity patches for 2.4 and 2.6 series kernels fixes the bug mentioned in the recently announced expand_stack() security advisory. To clear up some ambiguities and misleading statements from the advisory, the vulnerability actually does not exist within the expand_stack() function, it applies only to systems with the SEGMEXEC feature enabled (i386 arch only as x86-64 uses PAGEEXEC), and applies to both the 2.4 and 2.6 patches released prior to 01/21.

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.

[01/12] grsecurity 2.1.10 released for Linux 2.4.34/2.6.19.2

grsecurity 2.1.10 was released today for Linux 2.4.34 and 2.6.19.2. Changes in this release include:

• 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

[12/15] grsecurity 2.1.9 updated for Linux 2.4.33.4/2.6.19.1

grsecurity has been updated for the 2.4.33.4 and 2.6.19.1 Linux kernels. Changes include PaX updates involving the removal of RANDEXEC from the codebase (which had been removed from the configuration for several releases), and x86_64 support for disabling of raw I/O. There have been no changes to gradm.

[10/07] grsecurity 2.1.9 updated for Linux 2.6.18

grsecurity has been updated for the 2.6.18 Linux kernel. Gradm has been updated as well to perform an additional check for bad policies.

[09/03] grsecurity 2.1.9 updated for Linux 2.4.33.3/2.6.17.11

grsecurity 2.1.9 has been updated for the 2.4.33.3 and 2.6.17.11 Linux kernels. Changes include minor PaX changes, stealth module fixes for 2.6, and a change to the patch for the 2.4 Makefile so that each upcoming 2.4.x.y release won't require a new grsecurity patch to patch all files cleanly.

[08/23] grsecurity 2.1.9 updated for Linux 2.4.33.2/2.6.17.11

grsecurity 2.1.9 has been updated for the 2.4.33.2 and 2.6.17.11 kernels. A bug in the 2.4 kernel that caused the kernel not to boot when UDEREF was enabled has been fixed. Other minor changes were made to PaX and gradm.

[08/13] grsecurity 2.1.9 updated for Linux 2.4.33/2.6.17.8

grsecurity 2.1.9 has been updated for the 2.4.33 and 2.6.17.8 Linux kernels. Changes were minor: fix a crash on shutdown with PaX's uderef feature, correct sysctl error code in grsecurity, and fixed compiler warnings in the stealth module on the 2.6 patch.