if you read further a bit you'll see how we're saved by our vision of having a coherent set of defenses.
yes but it's admin settable. the kernel cannot solve this, it's a codegen issue fundamentallly, no different from NX/ASLR/etc.
1
i believe babies need to take baby steps first, so cut your teeth on the public version that you promised a year ago already ;).
what leaks do you need? for spraying or content? if the latter, assume you know static addresses/content (vmlinux/modules).
1
what probing do you mean? the kernel doesn't do anything like that, it enforces a heap-stack gap instead (in PaX since 2010AD).
1
e.g., grsec's brute force prevention had to be disabled to be able to trigger the bug at all. PaX doesn't have such by design.
you're responsible for your actions, not Qualys (their advisory makes it quite clear what they did and did not do).
this is just ridiculous, you can't even explain what exactly is wrong (and thus how to correct it). no kernel enforced gap size is safe.
you gave it a CVE, not Qualys. since you failed to discuss it with us, now's the time (to rescind it).
it's in the advisory: "it has a good chance of gaining eip control after 2^17 * 5.5 seconds = 200 hours"
1
Red Hat's @kurtseifried thinks that 200 hours of brute force is a defense failure. smells like sour grapes for having ignored the problem.
2
4
i got no email to reply to, instead you took to twitter for your disparaging remarks, not me or Qualys.
3
basically you're misunderstanding or misrepresenting the kernel-side gap feature. like i said, this CVE will go away, it's undefendable.
2
200h of bruteforce? are you kidding me? besides, what is a non-vulnerable gap value? anything can be jumped with the right bug.
An Ancient Kernel Hole is (Not) Closed: grsecurity.net/an_ancient_ke…. A lesson in real non-embargoed security.
66
3
57