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!
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!
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!
On Wed, Jan 3, 2018 at 12:22 PM Alex Elsayed eternaleye@gmail.com wrote:
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.
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 ...
On Wed, 03 Jan 2018 20:40:23 +0000, Tom Mitchell wrote:
On Wed, Jan 3, 2018 at 12:22 PM Alex Elsayed eternaleye@gmail.com 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...
It seems the snazzy site with a snazzy name and snazzy papers has landed:
We are currently working on an seL4 fix for Meltdown.
Ihor.
On 4 Jan 2018, at 9:35 am, Alex Elsayed eternaleye@gmail.com wrote:
It seems the snazzy site with a snazzy name and snazzy papers has landed:
Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
On Wed, Jan 3, 2018 at 1:37 PM, Alex Elsayed eternaleye@gmail.com wrote:
On Wed, 03 Jan 2018 20:40:23 +0000, Tom Mitchell wrote:
On Wed, Jan 3, 2018 at 12:22 PM Alex Elsayed eternaleye@gmail.com wrote:
On Tue, 02 Jan 2018 00:50:46 +0000, Adrian.Danis wrote:
Hi Corey,
It is definitely an interesting problem,
I said
I am not sure the memory iś arbitrary as much as random...
...
I'm not sure what you mean by "random" - the proof of concept takes an
....
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://sel4.systems/lists/listinfo/devel
Thank you for the update... My hints were early and not specific.
On Wed, Jan 3, 2018 at 4:37 PM, Alex Elsayed eternaleye@gmail.com wrote:
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/
Contrary to the PR, Intel CPUs do indeed have a design flaw aka bug which makes them vulnerable to Meltdown. Meltdown has not been reproduced on ARM or AMD and AMD thinks Meltdown is not applicable to their chips due to architectural differences.
The Spectre attack is the attack that is applicable across the board.
As far as Linux is concerned only Intel machines will be hit with the KPI-related slowdown (5%-30%) since KPI will be disabled on AMD CPUs. (And I assume this goes for Windows too.) This looks bad for Intel, hence the FUD.
-
Adrian.Danis＠data61.csiro.au -
Alex Elsayed -
Corey Richardson -
Ihor.Kuz＠data61.csiro.au -
Jeroen "Slim" van Gelderen -
Tom Mitchell