Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall | Date | Wed, 17 Apr 2019 15:53:36 +0000 |
| |
From: Theodore Ts'o > Sent: 17 April 2019 16:16 > 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?
Or extract information that should only be known by ring 0. I fairly sure many of the side-channel attacks not only require ring 3 access, but also the ability to request ring 0 repeatedly perform a specific action on an otherwise idle system.
> 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. :-( > > 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.
Some of these 'random' values have a short lifetime - and would need to be cracked quickly to be of any use.
I suspect that combining the output three linear generators with addition not xor would make it computationally much harder to reverse.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |