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

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.

Permalink for comment 652439
To read all comments associated with this story, please click here.
RE: Overhyped
by Alfman on Wed 3rd Jan 2018 05:21 UTC in reply to "Overhyped"
Member since:


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:

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.
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