Messages in this thread | | | From | Kees Cook <> | Date | Wed, 17 Apr 2019 10:40:41 -0500 | Subject | Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall |
| |
On Wed, Apr 17, 2019 at 10:17 AM Theodore Ts'o <tytso@mit.edu> wrote: > > On Wed, Apr 17, 2019 at 09:28:35AM +0000, David Laight wrote: > > > > If you can guarantee back to back requests on the PRNG then it is probably > > possible to recalculate its state from 'bits of state'/5 calls. > > Depend on the PRNG this might be computationally expensive. > > For some PRNG it will be absolutely trivial. > > ... > > Stirring in a little bit of entropy doesn't help much either. > > The entropy bits are effectively initial state bits. > > Add 4 in with each request and 128 outputs gives 640 linear > > equations in the (128 + 4 * 128) unknowns - still solvable. > > This is basically a scenario where the attacker has already taken > control of Ring 3 execution and the question is how hard is it for > them to perform privilege escalation attack to ring 0, right? I'm > sure the security folks will think I'm defeatist, but my personal rule > of thumb is if the attacker has ring 3 control, you've already lost > --- I figure there are so many zero days that getting ring 0 control > is a foregone conclusion. :-(
I think this attitude comes from Linux traditionally having had such a weak line between ring 3 and ring 0. That's what we're trying to fix, generally speaking. :)
> So that basically means if we want to protect against this, we're > going to do something which involves Real Crypto (tm). Whether that's > RDRAND, or using Chacha20, etc., or something that has some attack > resistance, such as "half MD5", etc., but emminently crackable by > brute force, is essentially a overhead vs. security argument, and what > it is we are willing to pay.
I wonder how a separate per-cpu state combined with frequent reseeding would compare to chacha20 (or RDRAND)?
Another point to consider is that this weakness depends on a separate bug existing, which is becoming less and less likely, given the always-init options now available. I don't think we should try to over-engineer this too much. Best-effort here seems fine. Using a stack leak when the stack is randomized may also prove difficult, so there's some chicken-and-egg problems with the proposed threat...
-- Kees Cook
| |