Recently in Lies and silence Category

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.

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.

diff --git a/arch/x86/kernel/vmi_32.c b/arch/x86/kernel/vmi_32.c
index 6ca515d..edfb09f 100644
--- a/arch/x86/kernel/vmi_32.c
+++ b/arch/x86/kernel/vmi_32.c
@@ -235,7 +235,7 @@ static void vmi_write_ldt_entry(struct desc_struct *dt, int entry,
 				const void *desc)
 {
 	u32 *ldt_entry = (u32 *)desc;
-	vmi_ops.write_idt_entry(dt, entry, ldt_entry[0], ldt_entry[1]);
+	vmi_ops.write_ldt_entry(dt, entry, ldt_entry[0], ldt_entry[1]);
 }
 
 static void vmi_load_sp0(struct tss_struct *tss,

It's not truly clear if there's a reliable way to abuse this issue properly (since data passed to sys_modify_ldt goes through several checks and might not trigger the vulnerable code path right away). Although, the original commit mentions that it was discovered when JRE caused failures. In addition, vmi_ops.write_idt_entry might do further validation, thus reducing the issue to a mere denial of service in the worst case. Also, it affects only x86 VMI guests.

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 according to their true practices.

1. grsecurity 2.1.0 release / 5 Linux kernel advisories (LWN)
2. What RedHat doesn't want you to know about ExecShield (without NX) (Dailydave, May 2007)
3. Linux's unofficial security-through-coverup policy (Dailydave, July 2008)
4. Linux's Security Through Obscurity (Slashdot, July 2008)