* Kees Cook <keesc...@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
