Apparently there's been an increased interest on bringing Linux kernel security issues to attention, for the past few months. It is a natural reaction to a policy which has been long time tacitly agreed upon by mostly all people involved in Linux kernel development (and more so, those with security-relevant roles, particularly a specific vendor). That is, a policy of silence. It is no surprise that Linux security currently looks much better on paper and marketing propaganda than it does in reality.
It takes decent amounts of will and dedication to summarize, categorize and review every potential security vulnerability for such a huge project, requiring collaboration between different vendors, who might or might not have agendas of their own, conflicting the interests of the users, or the rest of vendors themselves. It takes approximately ten minutes for an average computer user to write a summary of why SELinux can help your organization cut down security risks.
What you don't now is that you will have to go through the learning curve of writing policies, reviewing all software being used (including commercial applications which might not conflict with any 'learning' mode at kernel level, but consistently prevent targeted reverse engineering or make it even more tiresome), testing the setup and adapting its architecture to the real needs of your organization. MLS is rarely used out of certain circles.
October 2009 Archives
Continue reading Why Linux security has failed (for the past 10 years).
Few months after the publication of the original "Linux Kernel Heap Tampering Detection" paper in Phrack Magazine 66, we are proud to announce the availability of KERNHEAP. The implementation has built on several of the ideas described in detail in the paper. There are several improvements and changes not covered by the article, which are significant enough to be explained in a more or less detailed manner in this announcement.
Without further ado, KERNHEAP is available at http://www.subreption.com/kernheap as patches applicable to the latest stable 2.6 Linux kernel revision.
What's new?
The page sanitization functionality has been removed, in favor of using KERNHEAP along PaX, which provides a (unconditional) memory sanitization feature. In the near future, a SLAB flag might be added to support allocation-level sanitization.
The vmalloc vmap structures are now stored in an isolated cache, instead of a generic kmalloc cache. This helps to avoid certain cases in which a SLAB buffer overflow scenario could corrupt a neighboring vmap area structure, leading to potentially exploitable conditions during list walking in the vmap routines, where checks have been implemented to validate pointer correctness.
Full support against double frees and other types of heap corruption has been implemented for SLAB, SLUB and SLOB (the latter currently with limited functionality, users of SLOB would be better off moving to SLAB). Cache and slab meta-data is protected as well.
Currently only x86 and UML have been tested (you can protect User-Mode Linux kernels with KERNHEAP seamlessly).
Poisoning and the "pit" area
This change affects architectures with a fixmap, currently x86 and User-Mode Linux (UML) have been tested (the latter lacks a fixmap implementation). Poisoning alone is architecture-independent.
Every cache contains two unsigned long values, for poisoning uninitialized and free objects. If the architecture supports a fixmap, these values are randomized within a range, pointing to a reserved top memory location (a "mapping" within the fixmap). The page fault handler is modified to include a special case to handle accesses to this region. This allows us to reliably detect use of uninitialized or already released objects, as well as poisoning other pointer values (such as list nodes after unlinking).
This region is referred to (in KERNHEAP source code and documentation) as "the pit".
Architectures without fixmap support are unsupported, and will require editing the patch to avoid using fixmap-based poison address values. This would be done in the same way UML support is written, it is a simple change.
SAFELIST
KERNHEAP now provides more than mere safe unlinking. List nodes have their pointers poisoned after unlinking and the correctness of the nodes is verified during certain core operations. This provides robust protection against most forms of corruption in all linked lists. In the near future, protection for other similar interfaces might be implemented.
KERNHEAP and PaX or grsecurity
We recommend using PaX and KERNHEAP together, since PaX features can benefit from the meta-data corruption protections (among other things, for example for USERCOPY) and KERNHEAP itself can benefit from KERNEXEC and other protections to deter kernel exploitation. The patches shouldn't conflict with each other, but any potential conflict can be easily solved, either manually or through a "pax-compat" patch available in the distribution site.
Support and sponsoring
At the moment, KERNHEAP is developed by Subreption LLC. We do not offer support to organizations and individuals, apart of bug fixes, maintaining up to date patches and developing new features as we see fit. If you are interested on custom solutions or support for your organization related with KERNHEAP, or you are interested on sponsoring its development, contact us.
Without further ado, KERNHEAP is available at http://www.subreption.com/kernheap as patches applicable to the latest stable 2.6 Linux kernel revision.
What's new?
The page sanitization functionality has been removed, in favor of using KERNHEAP along PaX, which provides a (unconditional) memory sanitization feature. In the near future, a SLAB flag might be added to support allocation-level sanitization.
The vmalloc vmap structures are now stored in an isolated cache, instead of a generic kmalloc cache. This helps to avoid certain cases in which a SLAB buffer overflow scenario could corrupt a neighboring vmap area structure, leading to potentially exploitable conditions during list walking in the vmap routines, where checks have been implemented to validate pointer correctness.
Full support against double frees and other types of heap corruption has been implemented for SLAB, SLUB and SLOB (the latter currently with limited functionality, users of SLOB would be better off moving to SLAB). Cache and slab meta-data is protected as well.
Currently only x86 and UML have been tested (you can protect User-Mode Linux kernels with KERNHEAP seamlessly).
Poisoning and the "pit" area
This change affects architectures with a fixmap, currently x86 and User-Mode Linux (UML) have been tested (the latter lacks a fixmap implementation). Poisoning alone is architecture-independent.
Every cache contains two unsigned long values, for poisoning uninitialized and free objects. If the architecture supports a fixmap, these values are randomized within a range, pointing to a reserved top memory location (a "mapping" within the fixmap). The page fault handler is modified to include a special case to handle accesses to this region. This allows us to reliably detect use of uninitialized or already released objects, as well as poisoning other pointer values (such as list nodes after unlinking).
This region is referred to (in KERNHEAP source code and documentation) as "the pit".
Architectures without fixmap support are unsupported, and will require editing the patch to avoid using fixmap-based poison address values. This would be done in the same way UML support is written, it is a simple change.
SAFELIST
KERNHEAP now provides more than mere safe unlinking. List nodes have their pointers poisoned after unlinking and the correctness of the nodes is verified during certain core operations. This provides robust protection against most forms of corruption in all linked lists. In the near future, protection for other similar interfaces might be implemented.
KERNHEAP and PaX or grsecurity
We recommend using PaX and KERNHEAP together, since PaX features can benefit from the meta-data corruption protections (among other things, for example for USERCOPY) and KERNHEAP itself can benefit from KERNEXEC and other protections to deter kernel exploitation. The patches shouldn't conflict with each other, but any potential conflict can be easily solved, either manually or through a "pax-compat" patch available in the distribution site.
Support and sponsoring
At the moment, KERNHEAP is developed by Subreption LLC. We do not offer support to organizations and individuals, apart of bug fixes, maintaining up to date patches and developing new features as we see fit. If you are interested on custom solutions or support for your organization related with KERNHEAP, or you are interested on sponsoring its development, contact us.
