Messages in this thread | | | Date | Sun, 12 May 2019 10:02:45 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall |
| |
* Kees Cook <keescook@chromium.org> wrote:
> On Sat, May 11, 2019 at 03:45:19PM -0700, Andy Lutomirski wrote: > > ISTM maybe a better first step would be to make get_random_bytes() be > > much faster? :) > > I'm not opposed to that, but I want to make sure we don't break it for > "real" crypto uses...
I'm quite sure Andy implied that.
> I still think just using something very simply like rdtsc would be good > enough. > > This isn't meant to be a perfect defense: it's meant to disrupt the > ability to trivially predict (usually another thread's) stack offset.
But aren't most local kernel exploit attacks against the current task? Are there any statistics about this?
> And any sufficiently well-positioned local attacker can defeat this no > matter what the entropy source, given how small the number of bits > actually ends up being, assuming they can just keep launching whatever > they're trying to attack. (They can just hold still and try the same > offset until the randomness aligns: but that comes back to us also > needing a brute-force exec deterance, which is a separate subject...) > > The entropy source bikeshedding doesn't seem helpful given how few bits > we're dealing with.
The low number of bits is still useful in terms of increasing the probability of crashing the system if the attacker cannot guess the stack offset.
With 5 bits there's a ~96.9% chance of crashing the system in an attempt, the exploit cannot be used for a range of attacks, including spear attacks and fast-spreading worms, right? A crashed and inaccessible system also increases the odds of leaving around unfinished attack code and leaking a zero-day attack.
Thanks,
Ingo
| |