Re: [seL4] x86 kernel address space side channels

On Wed, 03 Jan 2018 20:40:23 +0000, Tom Mitchell wrote:

On Wed, Jan 3, 2018 at 12:22 PM Alex Elsayed wrote:

...

On Tue, 02 Jan 2018 00:50:46 +0000, Adrian.Danis wrote:

...

Hi Corey,

It is definitely an interesting problem, although only occurs since Linux 'relies' on ASLR in the kernel for security due to running untrustworthy code in kernel mode. seL4 does not implement KASLR, as seL4 does not have the classes of bugs that ASLR attempts to mitigate the exploitability of. From that side, there is nothing for us to do.

Some more information has come out, and it looks like this is _not_ just an ASLR break - it appears that, at very least, it is possible to read arbitrary kernel memory:

https://twitter.com/brainsmoke/status/948561799875502080

The PoC in that post is given an address with kernel-only page permissions (here, the address of the syscall table), and then uses the vulnerability to extract the value at that address (here, the first entry in the table - the address of the read syscall implementation) via a speculative execution timing side channel.

I am not sure the memory iś arbitrary as much as random...

The biggest hit will be sites that depend on VM to divide up resources. Virtulation adds a lot of trouble and risk to this....

I suspect the push is to not be efficient or clever but first to slam the door on this problem. It impacts both Linux and WindowZ on hardware going back ten years possibly more. There will be no new silicon for the old socket systems so software fixes are required. It might kill sales of the new eighth generation parts and systems. Fixed ""ninth"" generation parts will be 30% faster if nothing else changes.

Difficult problem for CIOs ...

(re-structured to use a consistent reply style) I'm not sure what you mean by "random" - the proof of concept takes an address and outputs (value, timing) pairs, where the low time indicates confirmation. It was invoked with the address of the syscall table (in kernelspace), and successfully read a 16-bit value at that location. As the first syscall is `read`, and x86 is little-endian, these were the low 16 bits of the function pointer for the internal kernel handler for `read(2)`. The clear result is that an unprivileged attacker can read 16-byte values from arbitrary addresses in kernel memory, with the mitigation being KPTI (full separation of user/kernel page tables). In addition, Intel has published a press release, claiming that this issue (counter to some claims elsewhere) does in fact affect other vendors and architectures: https://newsroom.intel.com/news/intel-responds-to-security-research-findings...