Submitted by Jeremy on February 11, 2008 - 9:42am.
"All currently active Linux kernel versions are now released with a fix for this problem. We have released them through our normal channels, with the needed information as to what the problem is, a pointer to the CVE number, and the patch itself."
As I understand it, a new system call was introduced and it didn't properly check all the parameters coming from user space.
There is nothing in this that is inherently Linux (or even kernel) specific. This is a classic failure to check untrusted parameters. It can and does occur anywhere, anytime; frequently.
If this had occurred in a network facing service (web server, email server, etc), then you'd have a remote exploit; that's really bad. In this case you have to be able to already compile/run code on the machine, so it's a local exploit. Not good, but not catastrophic like a remote root exploit is.
Could this kind of security
Could this kind of security flaw have happened to *BSD? I mean, is it inherent in the design of the linux kernel or its development model?
If it is
Find more exploits.
nothing special
As I understand it, a new system call was introduced and it didn't properly check all the parameters coming from user space.
There is nothing in this that is inherently Linux (or even kernel) specific. This is a classic failure to check untrusted parameters. It can and does occur anywhere, anytime; frequently.
If this had occurred in a network facing service (web server, email server, etc), then you'd have a remote exploit; that's really bad. In this case you have to be able to already compile/run code on the machine, so it's a local exploit. Not good, but not catastrophic like a remote root exploit is.
Slightly more complex
I think it's a bit more complex than a lack of parameter checking. LWN has, as always, an extremely detailed and informative examination of the exploit.
If you're not an LWN subscriber (and why aren't you?!?!) then it should be free starting tomorrow, I believe.