Kernel release status [LWN.net]

Kernel release status

Posted Sep 26, 2009 12:38 UTC (Sat) by spender (subscriber, #23067)
In reply to: Kernel release status by mingo
Parent article: Kernel release status

Ingo, always the one to come up with the contrived examples to save face.

First, tell me how long that config option has been in the kernel. Then, please tell me, for how long has that feature you mention actually worked? (This part might be difficult to figure out because no one at your company bothered to make sure it actually worked after they threw the code in the kernel). Also please tell me how many distro configurations actually use it. My videos should give you a hint.

PS: didn't a whole ton of stack infoleaks just get fixed? And isn't that cookie per-process (allowing me to perform repeated infoleaks in the same process as my exploit to determine the stack cookie)? I'm sure after finding a dozen of those in the past month, there aren't any more laying around to exploit. Oh, right.

-Brad

(Log in to post comments)

Kernel release status, StackProtector

Posted Sep 26, 2009 12:57 UTC (Sat) by mingo (subscriber, #31122) [Link]

Ingo, always the one to come up with the contrived examples to save face.

There's no need for me to save face - my face is blushing deep red from having let that hole slip through - i should do better than that.

I take your reply as a confirmation that CONFIG_CC_STACKPROTECTOR=Y indeed stops your exploit dead in its tracks - good to hear independent confirmation of such things.

FYI, a number of distributions that care about security features have CONFIG_CC_STACKPROTECTOR=Y enabled by default, such as Fedora:

 spirit:~> grep STACKPROT /boot/config-2.6.31-0.204.rc9.fc12.x86_64
 CONFIG_CC_STACKPROTECTOR_ALL=y
 CONFIG_CC_STACKPROTECTOR=y

So the bug is not exploitable on those distros.

Whether distributions are exploitable is a relevant piece of information: it influences how urgently a system administrator upgrades a kernel. A local root exploit is treated at a different severity level from a local DoS in most places. You probably know that.

That does not make it in any way better or worse kind of bug - it simply adds to the pool of information about this bug and about the exploit - a piece of information you either did not know about or which you chose not to disclose.

Thanks,

Ingo

Kernel release status, StackProtector

Posted Sep 26, 2009 13:26 UTC (Sat) by spender (subscriber, #23067) [Link]

Here we go again with the contrived (and misleading) examples. You quote the config of FC12, a distro that hasn't even shipped yet.

How about something like FC11, a distro that does actually exist, which I exploited in my video with a fully patched system using their config?

How about the latest version of Ubuntu x64, a distro that does actually exist, which I exploited in my video with a fully patched system using their config?

Can you name *any* distro that isn't a contrived example of a beta distro no-one is using that actually enables this feature?

-Brad

Kernel release status, StackProtector

Posted Sep 26, 2009 13:41 UTC (Sat) by mingo (subscriber, #31122) [Link]

How about something like FC11, a distro that does actually exist, which I exploited in my video with a fully patched system using their config?

FYI, the latest update kernel for Fedora 11 is v2.6.30 - while the bug only exists in v2.6.31.

If you wanted bleeding edge v2.6.31 you could have gone to rawhide (like i did). There the bug was present but not exploitable as a local root hole due to StackProtector catching it.

Instead you chose to build your own v2.6.31 kernel for Fedora 11, using the v2.6.30 config - not the v2.6.31 rawhide config (which has stackprotector enabled).

That's how you were able to exploit it. Had you used the F11 kernel, or had you used the v2.6.31 rawhide kernel you'd not have been able to exploit it.

(Again - this does not remove anything from my (serious) responsibility over this bug. It just adds to the pool of information.)

Thanks,

Ingo

Kernel release status, StackProtector

Posted Sep 26, 2009 13:45 UTC (Sat) by spender (subscriber, #23067) [Link]

"Unexploitable" isn't a term I would use. As I mentioned, it just takes an infoleak on the stack or per-cpu data to determine the cookie and then use this in the exploit payload. That a particular exploit is stopped doesn't logically imply that a working exploit cannot be written.

I can write such an exploit just for you, but since I'd be writing it just to prove a point to you (which I shouldn't have to do, see above re: taking some security training courses), you'd have to do something more for me than just stop using the word "unexploitable."

I'm open to ideas.

-Brad

Kernel release status, StackProtector

Posted Sep 27, 2009 10:37 UTC (Sun) by nix (subscriber, #2304) [Link]

Does this feature actually work on x86 these days? Last time I looked at
it it only worked on x86-64, which ruled it out for pretty much every
external-facing system I run (as they tend to be old cheap x86-32s).