Viewing posts for the category Linux
Why Linux security has failed (for the past 10 years)
Posted by: Subreption LLC in Linux 2 years, 6 months ago 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. Tags: linux mls selinux grsecurityread more / Comments
KERNHEAP for the Linux kernel 2.6 released
Posted by: Subreption LLC in Linux Security Research & Development 2 years, 6 months ago 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. Tags: kernheap linux mitigationsread more / Comments
Linux Kernel Silent Patching: VMI write_ldt_entry() privilege escalation
Posted by: Subreption LLC in Linux Security Critiques 3 years, 6 months ago Once again, the Linux kernel developers delight us with their always discreet (read: silent, no-advisory, no-warning policy) and wonderful patching practices. Sometime between 2.6.24 and 2.6.25 a patch from a Red Hat developer was committed into the Linux kernel git tree, implementing changes to the VMI interfaces hooking some functions dealing with the GDT and LDT. Tags: linuxread more / Comments
Linux kernel developers silently patching issues? No way!
Posted by: Subreption LLC in Linux Security Critiques 3 years, 10 months ago Alright, this might be the first article on the "Silent Patches" series, starting today and possibly lasting... forever. So, let's get to the business. Brad "spender" Spengler is pissed, and that's already a bad thing for the many people that knowingly or not, take advantage of his work and that from the guy or guys behind PaX, to be referred as The PaX Team, or Those Smart Guys Teaching Security On LKML. spender and the PaX Team have possibly contributed the most important advances in proactive defense technology for the past decade. ASLR was there before it became a marketing buzzword, NX and memory protections enforcement existed way before Red Hat pushed ExecShield to the Linux kernel and TCP & UDP source port randomization have been known for a while (even though now they seem to be the world's new internet superheroes with all this DNS the-end-is-nigh media frenzy). If you have used grsecurity in the past few years, you've used what Microsoft, Apple and Red Hat pretended to market as brand new technology baked in their very own development cubicles. The story now is how the Linux kernel developers managed to absolutely and irremediably piss off the very same people that fed them with security research and technology that really worked as expected. The very same people that have patched upstream vulnerabilities in their "third-party patches". Back in 2005 (see [1]) this was already happening. The fact that now we have a handy git interface where we can retrieve commit logs without difficulty just helps to pinpoint the silently patched issues and identify potentially hot issues. Our take on this fracas is that spender and the PaX Team are rock-solid consistent with their arguments, and that the Linux kernel development people should definitely change their alleged full-disclosure policy text with one more accurate accordingto their true practices. read more / Comments- < Previous
- 1