Stable kernel 2.6.25.10 [LWN.net]

Stable kernel 2.6.25.10

Posted Jul 3, 2008 23:43 UTC (Thu) by vonbrand (subscriber, #4458)
In reply to: Stable kernel 2.6.25.10 by PaXTeam
Parent article: Stable kernel 2.6.25.10

Re: 1: "... unfortunately, we don't learn whether this is actually possible or not..." Pardon me, it doesn't matter if it could be exploited or not, the one doing the checking that it is not a real vulnerability could make a mistake, or a later change could make it exploitable. Better check.

Re: 2: The kernel is the most privileged piece of software on the machine, mistakes that would be a minor annoyance elsewhere are very serious and potentially disastrous here. Nothing particular to disclose...

(Log in to post comments)

Stable kernel 2.6.25.10

Posted Jul 4, 2008 3:37 UTC (Fri) by spender (subscriber, #23067) [Link]

Except for when you own the kernel and disable SELinux entirely.

-Brad

Stable kernel 2.6.25.10

Posted Jul 4, 2008 9:30 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]

i'm not sure you entirely understand this whole userland/kernel separation thing and the issue
of privilege elevation. the short story is that your CPU offers privileged instructions and a
corresponding privileged operation mode (or modes) that are, well, privileged, not meant to be
executed by normal userland because of their impact on the security model implemented by the
kernel. think of, say, page table manipulation, modifying credentials information stored in
kernel (read: privileged) memory, etc. if there is a bug in privileged code that userland can
abuse in order to elevate its own privilege then that is called a security problem and people
*do* care about them (whether you personally care about such security problems is your
business of course, but you don't get to tell what others care about). since not all kernel
bugs can be abused for privilege elevation, it is very important and in accordance with the
disclosure policy declared by the kernel devs to disclose such information.

Stable kernel 2.6.25.10

Posted Jul 4, 2008 14:32 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

Yes, I do understand this stuff. But I've also fixed bugs that turned out (later!) to be security vulnerabilities. Sure, "possible buffer overflow" (and other classes) is a big warning sign, but not a guarantee that it is exploitable.

I much prefer kernel (and other) developers fixing bugs than running around finding out if bugs can be exploited. And a bug that can't be exploited today might become exploitable in the future due to changes elsewhere. Finding out if a bug is exploitable is a different skill than development.

Stable kernel 2.6.25.10

Posted Jul 4, 2008 14:54 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]

> Yes, I do understand this stuff.

so what made you say that a refcount overflow or a null function pointer dereference are not
security issues worthy of disclosure? if even you are aware of these exploitable bug classes,
then certainly we can expect kernel devs dealing with security issues to know better as well.

> But I've also fixed bugs that turned out (later!) to be security vulnerabilities.

i wasn't talking about bugs whose security impact was realized only later. in this case both
bugs are representative of well known exploitable bug classes, and at least one of them was
discussed on vendor-sec, yet no CVE or any sort of disclosure is in sight.

> Sure, "possible buffer overflow" (and other classes) is a big warning
> sign, but not a guarantee that it is exploitable.

in which case the prudent approach is to err on the side of safety and declare it as a
potentially exploitable bug, not covering it up for good.

> I much prefer kernel (and other) developers fixing bugs than running
> around finding out if bugs can be exploited.

you're welcome to read the previous threads as this has been discussed already: noone expects
kernel devs to do this kind of evaluation. what people do expect from them is following
Documentation/SecurityBugs and disclose security impact information when they're aware of it.

besides, they're well aware of severaly exploitable bug classes, they don't have to find out
anything to mention that detail in the commit.

> And a bug that can't be exploited today might become exploitable in the
> future due to changes elsewhere.

are you suggesting that kernel devs leave bugs unfixed in the hope they become actually
exploitable in the future? else the above doesn't make any sense, if a bug is known and fixed,
how can it become exploitable in the future?

> Finding out if a bug is exploitable is a different skill than development.

agreed and it's not the subject of this discussion.