Bug exposes eight years of Linux kernel
Passes it's-not-crying-wolf test
Linux developers have issued a critical update for the open-source OS after researchers uncovered a vulnerability in its kernel that puts most versions built in the past eight years at risk of complete takeover.
The bug involves the way kernel-level routines such as sock_sendpage react when they are left unimplemented. Instead of linking to a corresponding placeholder, (for example, sock_no_accept), the function pointer is left uninitialized. Sock_sendpage doesn't always validate the pointer before dereferencing it, leaving the OS open to local privilege escalation that can completely compromise the underlying machine.
"Since it leads to the kernel executing code at NULL, the vulnerability is as trivial as it can get to exploit," security researcher Julien Tinnes writes here. "An attacker can just put code in the first page that will get executed with kernel privileges."
Tinnes and fellow researcher Tavis Ormandy released proof-of-concept code that they said took just a few minutes to adapt from a previous exploit they had. They said all 2.4 and 2.6 versions since May 2001 are affected.
Security researchers not involved in the discovery were still studying the advisory at time of writing, but at least one of them said it appeared at first blush to warrant immediate action.
"This passes my it's-not-crying-wolf test so far," said Rodney Thayer, CTO of security research firm Secorix. "If I had some kind of enterprise-class Linux system like a Red Hat Enterprise Linux...I would really go check and see if this looked like it related, and if my vendor was on top of it and did I need to get a kernel patch."
This is the second time in less than a month that a serious security vulnerability has been reported in the Linux kernel. In mid July, a researcher alerted Linux developers to a separate "NULL pointer dereference" bug that put newer versions at risk of complete compromise. The bug, which was located in several parts of the kernel, attracted plenty of notice because it bit even when SELinux, or Security-Enhanced Linux, implementations were running.
Disgruntled employee much? (Many employees are disgruntled long before they are shown the door.)
Luckily, I removed my last Linux install the other day. It just wasn't worth the effort.
Re: Unintended Consequences
Whilst consequences may be unintended, they certainly shouldn't be unforeseeable! The programming language should make it very clear what the programmer can and can't rely on (with regards optimisation). Either the programmer would be at fault for not understanding the language, or the compiler for not implementing it properly.