As you read this article, replace every mention of ‘Malware’ with ‘Government Surveillance’ and every mention of ‘Hacker’ with ‘NSA’.
‘Kernel memory leaking’ Intel processor design flaw forces Linux, Windows redesign
By John Leyden and Chris Williams, The Register
2 Jan 2018
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 (Process-Context Identifiers) – to reduce the performance hit. Your mileage may vary.
Similar operating systems, such as Apple’s 64-bit macOS, will also need to be updated – the flaw is in the Intel x86-64 hardware, and it appears a microcode update can’t address it. It has to be fixed in software at the OS level, or go buy a new processor without the design blunder.
Details of the vulnerability within Intel’s silicon are under wraps: an embargo on the specifics is due to lift early this month, perhaps in time for Microsoft’s Patch Tuesday next week. Indeed, patches for the Linux kernel are available for all to see but comments in the source code have been redacted to obfuscate the issue.
However, some details of the flaw have surfaced, and so this is what we know.
It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.
The fix is to separate the kernel’s memory completely from user processes using what’s called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines … was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.
Whenever a running program needs to do anything useful – such as write to a file or open a network connection – it has to temporarily hand control of the processor to the kernel to carry out the job. To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes’ virtual memory address spaces, although it is invisible to these programs. When the kernel is needed, the program makes a system call, the processor switches to kernel mode and enters the kernel. When it is done, the CPU is told to switch back to user mode, and reenter the process. While in user mode, the kernel’s code and data remains out of sight but present in the process’s page tables.
…
At best, the vulnerability could be leveraged by malware and hackers to more easily exploit other security bugs. However, there are companies out there who are trying to fix this with the help of vulnerability services similar to https://www.digitaldefense.com/solution-overview/scan/ to safeguard their programmes.At worst, the hole could be abused by programs and logged-in users to read the contents of the kernel’s memory. Suffice to say, this is not great. The kernel’s memory space is hidden from user processes and programs because it may contain all sorts of secrets, such as passwords, login keys, files cached from disk, and so on. Imagine a piece of JavaScript running in a browser, or malicious software running on a shared public cloud server, able to sniff sensitive kernel-protected data.
Specifically, in terms of the best-case scenario, it is possible the bug could be abused to defeat KASLR: kernel address space layout randomization. This is a defense mechanism used by various operating systems to place components of the kernel in randomized locations in virtual memory. This mechanism can thwart attempts to abuse other bugs within the kernel: typically, exploit code – particularly return-oriented programming exploits – relies on reusing computer instructions in known locations in memory.
If you randomize the placing of the kernel’s code in memory, exploits can’t find the internal gadgets they need to fully compromise a system. The processor flaw could be potentially exploited to figure out where in memory the kernel has positioned its data and code, hence the flurry of software patching.
However, it may be that the vulnerability in Intel’s chips is worse than the above mitigation bypass. In an email to the Linux kernel mailing list over Christmas, AMD said it is not affected. The wording of that message, though, rather gives the game away as to what the underlying cockup is:
AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.
A key word here is “speculative.” Modern processors, like Intel’s, perform speculative execution. In order to keep their internal pipelines primed with instructions to obey, the CPU cores try their best to guess what code is going to be run next, fetch it, and execute it.
It appears, from what AMD software engineer Tom Lendacky was suggesting above, that Intel’s CPUs speculatively execute code potentially without performing security checks. It seems it may be possible to craft software in such a way that the processor starts executing an instruction that would normally be blocked – such as reading kernel memory from user mode – and completes that instruction before the privilege level check occurs.
That would allow ring-3-level user code to read ring-0-level kernel data. And that is not good.
The specifics of the vulnerability have yet to be confirmed, and this discussion of its severity is – aptly enough – speculation, but consider this: the changes to Linux and Windows are significant and are being pushed out at high speed. That suggests it’s more serious than a KASLR bypass.
Translated from GobbletyGeek what that means is that Spy Programs and more destructive Viruses like Ransomware and those that trash your Hard Drive just for sport can easily (well, you have to know what you’re doing) take complete control of your computer whenever you merely visit a web site.
But that’s old news you say?
Here’s what’s new- Operating Systems and Anti-Virus Programs can’t do a damn thing about it without slowing down your computer from 5% to 30% because it’s built into the CPU!
Now do I really believe the NSA and Intel conspired to insert this vulnerability in the Silicon?
Let me put it this way, at best Intel has been cheating to make its hardware appear faster than it is. That’s the charitable explanation.
Me? I’m solid AMD and have been for decades. Intel sucks.
What can you do? Well, Linux already has a patch in the latest kernel, Microsoft is coming soon. Apple macOS hardly seems to have noticed, but it’s not a company focus and Apple is notoriously close mouthed about these kind of things so who knows.
All of these “fixes” slow down your computer though. Us AMD types will notice no change at all.