Linked by Thom Holwerda on Wed 3rd Jan 2018 00:42 UTC
Intel

A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.

Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.

Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features - such as PCID - to reduce the performance hit.

That's one hell of a bug.

Thread beginning with comment 652435
To read all comments associated with this story, please click here.
Overhyped
by Brendan on Wed 3rd Jan 2018 03:22 UTC
Brendan
Member since:
2005-11-16

Hi,

The minor timing quirk in Intel CPUs (that does not break documented behaviour, expected behaviour or any guarantee, and therefore can NOT be considered a bug in the CPU); allows an attacker to determine which areas of kernel space are used and which aren't.

It does not allow an attacker to read or modify the contents of any memory used by the kernel, and doesn't even tell the attacker what the areas of kernel space are being used for, and by itself is not a security problem at all. It only means that if there are massive security holes somewhere else, those massive security holes might or might not be a little bit easier to exploit. In other words; the main effect is that it makes "kernel address space randomisation" more ineffective at providing "security through obscurity" than it previously was.

Note that the insane hackery to avoid this non-issue adds significant overhead to kernel system calls; ironically, making the performance of monolithic kernels worse than the performance of micro-kernels (while still providing inferior security than micro-kernels). The insane hackery doesn't entirely fix the "problem" either (a small part of kernel must remain mapped, and an attacker can still find out where in kernel space that small part of the kernel is and use this information to infer where the rest of the kernel is).

Fortunately the "malicious performance degradation attack" (the ineffective work-around for the non-issue) is easy for end users to disable.

- Brendan

Reply Score: 1

RE: Overhyped
by panzi on Wed 3rd Jan 2018 04:32 in reply to "Overhyped"
panzi Member since:
2006-01-22

In any case, would that be exploitable via JavaScript? If not I don't care at all. Anything else I run already deliberately on my machine and it can access all my files anyway. And that is what matters to me, my files. Root cannot do more damage to me than a user process.

Reply Parent Score: 1

RE[2]: Overhyped
by Brendan on Wed 3rd Jan 2018 04:58 in reply to "RE: Overhyped"
Brendan Member since:
2005-11-16

Hi,

In any case, would that be exploitable via JavaScript? If not I don't care at all. Anything else I run already deliberately on my machine and it can access all my files anyway. And that is what matters to me, my files. Root cannot do more damage to me than a user process.


If you have poorly designed hardware (e.g. that is susceptible to "rowhammer") and a poorly designed kernel (e.g. a monolithic kernel where there's a strong relationship between virtual addresses used by the kernel and physical addresses); then in theory this minor timing quirk can make it a little easier for an attacker to exploit huge gaping security holes that should never of existed.

Javascript probably can't use the minor timing quirk (it relies on a strict access pattern involving the use of a "dodgy pointer" that will cause a page fault; and Javascript is designed not to support pointers or raw addresses); so an attacker using Javascript will exploit the gaping security holes without using the minor timing quirk.

- Brendan

Reply Parent Score: 2

RE: Overhyped
by Alfman on Wed 3rd Jan 2018 05:21 in reply to "Overhyped"
Alfman Member since:
2011-01-28

Brendan,

The minor timing quirk in Intel CPUs (that does not break documented behaviour, expected behaviour or any guarantee, and therefore can NOT be considered a bug in the CPU); allows an attacker to determine which areas of kernel space are used and which aren't.
...
Note that the insane hackery to avoid this non-issue adds significant overhead to kernel system calls; ironically, making the performance of monolithic kernels worse than the performance of micro-kernels (while still providing inferior security than micro-kernels). The insane hackery doesn't entirely fix the "problem" either (a small part of kernel must remain mapped, and an attacker can still find out where in kernel space that small part of the kernel is and use this information to infer where the rest of the kernel is).


Regarding address layout randomization, that is my position as well; it is nothing more than security by obscurity under a different name. Security that depends on keeping (non cryptographic) secrets like memory addresses is inherently flawed. However to play devil's advocate, it's proponents would argue it's intended as a secondary security measure and not a primary one. Security by obscurity, as flawed as it is, is arguably more secure than not having a second line of defense at all when an exploit for the primary security is found. ASLR was introduced as a very low overhead way to increase the failure modes for code exploits. However given the increasingly known failures of ASLR on non-theoretical hardware and the costs of repairing ASLR's broken assumptions, I'd say it's days as an effective countermeasure are numbered. In other words I don't think the community can justify the high costs that would be required to make ASLR strong against side channel attacks (like cache-hit testing).

This was the topic of a 2016 blackhat paper:
https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Ke...

Countermeasures are discussed at the very end...
Modifying CPU to eliminate timing channels
- Difficult to be realized

Using separated page tables for kernel and user processes
- High performance overhead (~30%) due to frequent TLB flush

Fine-grained randomization
- Difficult to implement and performance degradation

Coarse-grained timer?
- Always suggested, but no one adopts it.


As we know, nothing has been done to address sidechannel attacks against ASLR. Even a javascript version of the exploit was demonstrated last year just to illustrate how effective sidechannel attacks can be.

https://www.theregister.co.uk/2017/02/14/aslr_busting_javascript_hac...
This, the VU team says, is what makes this vulnerability so significant. An attacker could embed the malicious JavaScript code in a webpage, and then run the assault without any user notification or interaction.

Because the assault does not rely on any special access or application flaws, it works on most browsers and operating systems. The researchers say that when tested on up-to-date web browsers, the exploit could fully unravel ASLR protections on 64-bit machines in about 90 seconds.

Infecting a system does not end there, of course: it just means ASLR has been defeated.




Fortunately the "malicious performance degradation attack" (the ineffective work-around for the non-issue) is easy for end users to disable.


The problem is there's very little published info on this newest attack. The little bits that are around suggest to me this is much more significant than merely broken ASLR. It sounds like intel's out of order branch prediction may be executing speculative code prior to checking the full credentials in such a way that they found a way to exploit the deferment, which does not happen on AMD processors. Apparently the temporary software fix is to reload the page table every kernel invocation. This invalidates the caches and happens to fix ASLR as well, but I think fixing ASLR was just a side effect - there's not enough information to know for sure. I could be completely wrong but this media hush now would make very little sense if they had merely broken ASLR again given that ASLR is already publicly cracked and has been for ages already. I believe the sense of urgency and the deployment of high performance-cost workarounds in macos, windows, and linux, and planned service outages at amazon strongly suggest something much more critical was found to directly compromise kernel security on intel processors.

Hopefully Thom will post an update when all is finally revealed.

Edited 2018-01-03 05:27 UTC

Reply Parent Score: 7

RE[2]: Overhyped
by Brendan on Wed 3rd Jan 2018 06:14 in reply to "RE: Overhyped"
Brendan Member since:
2005-11-16

Hi,

The problem is there's very little published info on this newest attack. The little bits that are around suggest to me this is much more significant than merely broken ASLR. It sounds like intel's out of order branch prediction may be executing speculative code prior to checking the full credentials in such a way that they found a way to exploit the deferment, which does not happen on AMD processors. Apparently the temporary software fix is to reload the page table every kernel invocation. This invalidates the caches and happens to fix ASLR as well, but I think fixing ASLR was just a side effect - there's not enough information to know for sure. I could be completely wrong but this media hush now would make very little sense if they had merely broken ASLR again given that ASLR is already publicly cracked and has been for ages already. I believe the sense of urgency and the deployment of high performance-cost workarounds in macos, windows, and linux, and planned service outages at amazon strongly suggest something much more critical was found to directly compromise kernel security on intel processors.


As I understand it:

a) Program tries to do a read from an address in kernel space

b) CPU speculatively executes the read and tags the read as "will generate page fault" (so that a page fault will occur at retirement), but also (without regard to permission checks and likely in parallel with permission checks) either speculatively reads the data into a temporary register (if the page is present) or pretends that data being read will be zero (if the page is not present) for performance reasons (so that other instructions can be speculatively executed after a read). Note that the data (if any) in the temporary register can not be accessed directly (it won't become "architecturally visible" when the instruction retires).

c) Program does a read from an address that depends on the temporary register set by the first read, which is also speculatively executed, and because it's speculatively executed it uses the "speculatively assumed" value in the temporary register. This causes a cache line to be fetched for performance reasons (to avoid a full cache miss penalty if the speculatively executed instruction is committed and not discarded).

d) Program "eats" the page fault (caused by step a) somehow so that it can continue (e.g. signal handler).

e) Program detects if the cache line corresponding to "temporary register was zero" was pre-fetched (at step c) by measuring the amount of time a read from this cache line takes (a cache hit or cache miss).

In this way (or at least, something vaguely like it); the program determines if a virtual address in kernel space corresponds to a "present" page or a "not present" page (without any clue what the page contains or why it's present or if the page is read-only or read/write or executable or even if the page is free/unused space on the kernel heap).

- Brendan

Reply Parent Score: 5

RE: Overhyped
by oiaohm on Wed 3rd Jan 2018 08:02 in reply to "Overhyped"
oiaohm Member since:
2009-05-30

Note that the insane hackery to avoid this non-issue adds significant overhead to kernel system calls; ironically, making the performance of monolithic kernels worse than the performance of micro-kernels (while still providing inferior security than micro-kernels). The insane hackery doesn't entirely fix the "problem" either (a small part of kernel must remain mapped, and an attacker can still find out where in kernel space that small part of the kernel is and use this information to infer where the rest of the kernel is).

Please do not claim bogus. Microkernels fixed against this defect will in fact take a higher hit than a monolithic kernel. Kernel to usermode switching cost increases when you have to change complete page tables every single time changing from kernel to userspace and back. Microkernel do this way more often than Monolithic. The advantage of running drivers in kernel space.


This is not exactly a non issue. The fact userspace ring is interfering was able to detect kernel space pages was found in 2016. Now kernel space pages with wrong protective bits for any reason are also exposed due to that fault.

Small fragment mapped of kernel mapped in userspace does not provide enough information to work out the randomisation. Complete kernel mapped into userspace as Intel CPU have been doing down right does.

Small fragment mapped into user-space on independent page tables does not mean there is any relationship of that information once you enter kernel mode and switch to kernel mode TLB.

Also this mapping fix to work around Intel MMU/CPU design issue applied to a Microkernel in fact hurts worst. It some ways it explains why AMD cpu have been slightly slower in particular benchmarks.

Yes AMD MMU/CPU if you attempt to access ring 0 pages from ring 1-3 and they have not been mapped for you its not happening. Same with ring 1 from ring 2 and 3.

So that KASLR attack from 2016 did not work on AMD CPUs. So finding extra protection flaws also have no effect on AMD CPU because the KASLR attack from 2016 does not work. Its not that the AMD has different timing is better page memory rules enforced by hardware so most of the kernel ring 0 pages are basically non existent to the userspace code.

Really this is another reason why in the past it was require by the USA Mil for anything they acquired to come 3 vendors using compatible sockets. So a vendor glitch like this could have been fixed by changing chips.

There is security by obscurity and there is no be there. No be there is better. AMD cpu/mmu is doing no be there so userspace could not see all of the kernel space ring 0 pages and this makes solving the address randomisation of kernel next to impossible.

Intel was depending on obscurity that no one would hunt the memory and find out that complete kernel space pages and userspace pages were in fact exposed to userspace program. Then Intel prayed that memory protection settings would always be enforced and correct. There turned up a few case in 2017 where the memory protections were not always on. So now you have kernel pages exposed to userspace and userspace able to write them how can you say mega failure.

Implementing two page tables one for kernel space and one for userspace is about the only valid way to work around intel goof up. Please note this kind of fault dates back to the 286. All the AMD processors with built in MMU have had different behaviour so preventing the problem.

Reply Parent Score: 3

RE[2]: Overhyped
by Brendan on Wed 3rd Jan 2018 10:26 in reply to "RE: Overhyped"
Brendan Member since:
2005-11-16

Hi,

"Note that the insane hackery to avoid this non-issue adds significant overhead to kernel system calls; ironically, making the performance of monolithic kernels worse than the performance of micro-kernels (while still providing inferior security than micro-kernels). The insane hackery doesn't entirely fix the "problem" either (a small part of kernel must remain mapped, and an attacker can still find out where in kernel space that small part of the kernel is and use this information to infer where the rest of the kernel is)."

Please do not claim bogus. Microkernels fixed against this defect will in fact take a higher hit than a monolithic kernel. Kernel to usermode switching cost increases when you have to change complete page tables every single time changing from kernel to userspace and back. Microkernel do this way more often than Monolithic. The advantage of running drivers in kernel space.


Completely changing page tables is expensive. Windows and Linux will be doing this for every system call and every IRQ. For things that don't involve a driver (all scheduling, all memory management, etc) a micro-kernel won't change page tables (because there's "almost nothing" in kernel-space, and certainly no encryption keys or passwords or other sensitive data, and therefore there's no reason to bother) but the monolithic kernels will. This is the main reason that (after patches) monolithic kernels will be slower than micro-kernels.

For things that do involve a device driver, a micro-kernel and a monolithic kernel both change page tables and end up "similar". However, micro-kernels are *designed* knowing that there will be context switching costs and therefore the designers design everything to reduce/mitigate those costs (including things like postponing task switches in the hope of "one task switch instead of many" and things like having a single "do this list of things" message rather than doing one little thing per message). Monolithic kernels were never designed to mitigate these costs. This is the other reason that monolithic kernels will be slower than micro-kernels.

Note: the "address space ID" feature reduces the cost of changing page tables for both monolithic and micro-kernel; and therefore doesn't make monolithic (with these patches) "less worse" in comparison.

This is not exactly a non issue. The fact userspace ring is interfering was able to detect kernel space pages was found in 2016. Now kernel space pages with wrong protective bits for any reason are also exposed due to that fault.


Those were exposed anyway (just use a "for each page (try something)" loop and ignore any page faults).

Small fragment mapped of kernel mapped in userspace does not provide enough information to work out the randomisation. Complete kernel mapped into userspace as Intel CPU have been doing down right does.


That's not how it works. You have a virtual address space where user-space is in one area of the virtual address space and kernel is in another area, and where these areas are separated by privilege levels. Kernel has never been mapped into user-space.

Small fragment mapped into user-space on independent page tables does not mean there is any relationship of that information once you enter kernel mode and switch to kernel mode TLB.

Also this mapping fix to work around Intel MMU/CPU design issue applied to a Microkernel in fact hurts worst. It some ways it explains why AMD cpu have been slightly slower in particular benchmarks.

Yes AMD MMU/CPU if you attempt to access ring 0 pages from ring 1-3 and they have not been mapped for you its not happening. Same with ring 1 from ring 2 and 3.

So that KASLR attack from 2016 did not work on AMD CPUs. So finding extra protection flaws also have no effect on AMD CPU because the KASLR attack from 2016 does not work. Its not that the AMD has different timing is better page memory rules enforced by hardware so most of the kernel ring 0 pages are basically non existent to the userspace code.

Really this is another reason why in the past it was require by the USA Mil for anything they acquired to come 3 vendors using compatible sockets. So a vendor glitch like this could have been fixed by changing chips.

There is security by obscurity and there is no be there. No be there is better. AMD cpu/mmu is doing no be there so userspace could not see all of the kernel space ring 0 pages and this makes solving the address randomisation of kernel next to impossible.

Intel was depending on obscurity that no one would hunt the memory and find out that complete kernel space pages and userspace pages were in fact exposed to userspace program. Then Intel prayed that memory protection settings would always be enforced and correct. There turned up a few case in 2017 where the memory protections were not always on. So now you have kernel pages exposed to userspace and userspace able to write them how can you say mega failure.

Implementing two page tables one for kernel space and one for userspace is about the only valid way to work around intel goof up. Please note this kind of fault dates back to the 286. All the AMD processors with built in MMU have had different behaviour so preventing the problem.


Intel wasn't depending on obscurity - they didn't invent or implement "kernel address space randomisation". This probably came from one of the "hardened Linux" groups (SELinux? Grsecurity?) before being adopted in "mainline Linux" (and cloned by Microsoft).

As far as I know this problem *might* effect Pentium III and newer (and might only effect Broadwell and newer - details are hard to find). It does not effect 80286, 80386, 80486 or Pentium. 80286 doesn't even support paging (and doesn't do speculative execution either).

Don't forget that recent ARM CPUs are also effected - it's not just "Intel's goof up" (this time).

- Brendan

Reply Parent Score: 3

RE[2]: Overhyped
by Carewolf on Wed 3rd Jan 2018 12:32 in reply to "RE: Overhyped"
Carewolf Member since:
2005-09-08

"Note that the insane hackery to avoid this non-issue adds significant overhead to kernel system calls; ironically, making the performance of monolithic kernels worse than the performance of micro-kernels (while still providing inferior security than micro-kernels). The insane hackery doesn't entirely fix the "problem" either (a small part of kernel must remain mapped, and an attacker can still find out where in kernel space that small part of the kernel is and use this information to infer where the rest of the kernel is).

Please do not claim bogus. Microkernels fixed against this defect will in fact take a higher hit than a monolithic kernel.
"
No. Let me put is like this: Microkernels are already talking a similar hit as their context switches are from user to user, now Macrokernels get a similar hit by having to dump the virtual tables before going to user mode, just like each user's table are dropped when moving to another user.

Reply Parent Score: 3

RE: Overhyped
by tidux on Wed 3rd Jan 2018 19:55 in reply to "Overhyped"
tidux Member since:
2011-08-13

There's already an exploit in the wild using this to read kernel memory as a non-root user. All it takes is a bit of JavaScript downloading and executing such a binary and you're pwned.

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

Reply Parent Score: 4