| |||||||||||||
fixed in v2.6.31.1fixed in v2.6.31.1Posted Sep 25, 2009 12:17 UTC (Fri) by spender (subscriber, #23067)In reply to: fixed in v2.6.31.1 by hppnq Parent article: Kernel release status
Why would we submit a patch for the Linux kernel when a patch already existed for the bug and was queued for the 2.6.31.1 kernel? We can't control the fact that the stable team sat on the release for 2 weeks while public exploits circulated (I wasn't the only one to write one). And what fanfare are you talking about? Ingo complained that there wasn't enough fanfare apparently, that I should have emailed full-disclosure/dailydave like I usually do and gotten the information out to everyone, and then surely again I would be insulted by people like you (and Ingo) for being an attention seeker by doing so.
-Brad
(Log in to post comments)
fixed in v2.6.31.1 Posted Sep 25, 2009 18:09 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
if the fix was already in the release process, why release an exploit at all?
also, it's very common for the -stable release to wait until after the initial merge window before releasing 2.6.x.1 the same developers who do the -stable work also work on the main kernel and that is a very busy two weeks.
fixed in v2.6.31.1 Posted Sep 25, 2009 18:20 UTC (Fri) by foom (subscriber, #14868) [Link]
> if the fix was already in the release process, why release an exploit at all?
Apparently it takes the existence of a public exploit for a kernel bug's severity to be properly
fixed in v2.6.31.1, also caught by StackProtector Posted Sep 26, 2009 9:55 UTC (Sat) by mingo (subscriber, #31122) [Link] It simply was not known as an exploitable bug. When we know something is exploitable a -stable kernel is released immediately, within hours. (Let me know about a labeling method that actually works in practice - i'm not aware of any. Post facto labeling does not actually prevent bugs from getting mislabeled - it mostly only increases the security theatre - i.e. rewards the wrong kind of behaviour and the people who leech off of that.) Also, note that if you had StackProtector enabled (CONFIG_CC_STACKPROTECTOR_ALL=y), the bug is not exploitable into a local root hole but gets caught and the break-in attempt gets exposed:
[ 66.928106] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff810c49d2 [ 66.928109] [ 66.939059] Pid: 2628, comm: exploit Not tainted 2.6.31 #17228 [ 66.944947] Call Trace: [ 66.947423] [ffffffff81622ba6] panic+0x84/0x12f [ 66.952238] [ffffffff810c49d2] ? sys_perf_counter_open+0x660/0x672 [ 66.958729] [ffffffff810500cd] __stack_chk_fail+0x27/0x57 [ 66.964419] [ffffffff810c49d2] sys_perf_counter_open+0x660/0x672 It's a good thing we revived this feature in recent kernels, it already caught real kernel bugs and also catches exploit attempts.
fixed in v2.6.31.1, also caught by StackProtector Posted Sep 26, 2009 12:47 UTC (Sat) by spender (subscriber, #23067) [Link]
So I have the answer to my question above then: "Is it the case that yourself, Paul Mackerras, Xiao Guangrong, Greg Kroah-Hartman, Peter Zijlstra, Eugene Teo and the other members of oss-security *ALL* can not plainly see that trivial, classic stack overflows, like the one signed-off on the fix for, are exploitable for arbitrary code execution? Did you all really believe that it was purely a "kernel crash" as noted in the commit message you all reviewed and signed off on?"
Let the record show that the Linux kernel development community and oss-security can't spot the exploitability of a trivial stack overflow.
It would be funny if it weren't so pathetic.
-Brad
fixed in v2.6.31.1, also caught by StackProtector Posted Sep 26, 2009 13:16 UTC (Sat) by mingo (subscriber, #31122) [Link] So I have the answer to my question above then: "Is it the case that yourself, Paul Mackerras, Xiao Guangrong, Greg Kroah-Hartman, Peter Zijlstra, Eugene Teo and the other members of oss-security *ALL* can not plainly see that trivial, classic stack overflows, like the one signed-off on the fix for, are exploitable for arbitrary code execution? Did you all really believe that it was purely a "kernel crash" as noted in the commit message you all reviewed and signed off on?" Yes, it indeed happens. I take responsibility for this having slipped through (i should have caught it), and let me defend those other hard working people, who take an active part in the upstream kernel development process. Yes, nobody is infallible, and no, i dont think your repeated attempts to ridicule them is fair or justified. If you think you could do better then i'd invite you to take part in the process instead of taking pot shots at it externally. Otherwise you'll never know whether you could do better than those whom you attack so viciously. The fundamental question there (if you care): are you able to participate in a constructive community? Judging by your messages your life seems to be defined by hatred.
fixed in v2.6.31.1, also caught by StackProtector Posted Sep 26, 2009 13:20 UTC (Sat) by spender (subscriber, #23067) [Link]
I seem to recall someone talking about another exploit being unexploitable from stackprotector. Right, it was you:
http://www.pubbs.net/kernel/200904/62088/ "the vmsplice exploit would only have been caught by the -ALL variant."
How quickly you forgot this:
and the fact that you actually committed his fix (and so were involved in the discussion above):
Did you have any proof for that one? That SSP stops exploitation of a vuln that doesn't even involve overwriting a return address?
-Brad
fixed in v2.6.31.1, also caught by StackProtector Posted Sep 26, 2009 13:45 UTC (Sat) by mingo (subscriber, #31122) [Link] Did you have any proof for that one? That SSP stops exploitation of a vuln that doesn't even involve overwriting a return address? Indeed, i was wrong about that in the changelog, mea culpa. StackProtector has its place, but it would not have stopped the vmsplice exploit. Thanks, Ingo
|
|||||||||||||