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.

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.
> 
> Otherwise you are also correct, probing microarchitectural state to
> determine what another process is doing is a known and currently
> unsolvable[1] problem.
> 
> Adrian
> 
> [1] As far as is currently known and possible by the hardware ISA
> without truly prohibitive performance costs
> 
> On Mon 25-Dec-2017 10:37 AM, Corey Richardson wrote:
>> https://lwn.net/Articles/738975/
>> 
>> That's really painful, for Linux ;) I don't think seL4 is really
>> impacted? I'm having a hard time thinking about what sensitive
>> information could be disclosed by probing the kernel window. Maybe
>> which memory regions caps being accessed by other concurrently running
>> threads occupy? You could use that to make a covert channel, if the two
>> threads trying to communicate are running in parallel. It seems really
>> dubious that that could give you anything useful otherwise, and as the
>> literature shows timing side channels are unavoidable on x86.
>> 
>> Thought it was interesting and worth sharing!


_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel

Reply via email to