x4rgs
Member
- Nov 11, 2017
- 41
- 55
Here's a summary of the two branded bugs:
- Meltdown
- This is the big bug reported on Tuesday.
- It can be exploited by normal programs to read the contents of private kernel memory.
- It affects potentially all out-of-order execution Intel processors since 1995, except Itanium and pre-2013 Atoms. It definitely affects out-of-order x86-64 Intel CPUs since 2011. There are workaround patches to kill off this vulnerability available now for Windows, and for Linux. Apple's macOS has been patched since version 10.13.2. Installing and enabling the latest updates for your OS should bring in the fixes. You should go for it. If you're a Windows Insider user, you're likely already patched. Windows Server admins must enable the kernel-user space splitting feature once it is installed; it's not on by default.
- Amazon has updated its AWS Linux guest kernels to protect customers against Meltdown. Google recommends its cloud users apply necessary patches and reboot their virtual machines. Microsoft is deploying fixes to Azure. If you're using a public cloud provider, check them out for security updates.
- The workarounds move the operating system kernel into a separate virtual memory space. On Linux, this is known as Kernel Page Table Isolation, or KPTI, and it can be enabled or disabled during boot up. You may experience a performance hit, depending on your processor model and the type of software you are running. If you are a casual desktop user or gamer, you shouldn't notice. If you are hitting storage, slamming the network, or just making a lot of rapid-fire kernel system calls, you will notice a slowdown. Your mileage may vary.
- It also affects Arm Cortex-A75 cores, which aren't available yet. Qualcomm's upcoming Snapdragon 845 is an example part that uses the A75. There are Linux kernel KPTI patches available to mitigate this. The performance hit isn't known, but expected to be minimal.
- Additionally, Cortex-A15, Cortex-A57 and Cortex-A72 cores suffer from a variant of Meltdown: protected system registers can be accessed, rather than kernel memory, by user processes. Arm has a detailed white paper and product table, here, describing all its vulnerable cores, the risks, and mitigations.
- Meltdown does not affect any AMD processors.
- Googlers confirmed an Intel Haswell Xeon CPU would allow a normal user program to read kernel memory.
- It was discovered and reported by three independent teams: Jann Horn (Google Project Zero); Werner Haas, Thomas Prescher (Cyberus Technology); and Daniel Gruss, Moritz Lipp, Stefan Mangard, Michael Schwarz (Graz University of Technology).
- Spectre
- Spectre allows, among other things, user-mode applications to extract information from other processes running on the same system. Alternatively, it can be used by code to extract information from its own process. Imagine malicious JavaScript in a webpage churning away using Spectre bugs to extract login cookies for other sites from the browser's memory.
- It is a very messy vulnerability that is hard to patch, but is also tricky to exploit. It's hard to patch because just installing the aforementioned KPTI features is pointless on most platforms – you must recompile your software with countermeasures to avoid it being attacked by other programs, or wait for a chipset microcode upgrade. There are no solid Spectre fixes available yet for Intel and AMD parts.
- In terms of Intel, Googlers have found that Haswell Xeon CPUs allow user processes to access arbitrary memory; the proof-of-concept worked just within one process, though. More importantly, the Haswell Xeon also allowed a user-mode program to read kernel memory within a 4GB range on a standard Linux install.
- This is where it gets really icky. It is possible for an administrative user within a guest virtual machine on KVM to read the host server's kernel memory in certain conditions. According to Google:
When running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM.
- AMD insists its processors are practically immune to Variant 2 Spectre attacks. As for Variant 1, you'll have to wait for microcode updates or recompile your software with forthcoming countermeasures described in the technical paper on the Spectre website.
- The researchers say AMD's Ryzen family is affected by Spectre. Googlers have confirmed AMD FX and AMD Pro cores can allow arbitrary data to be obtained by a user process; the proof-of-concept worked just within one process, though. An AMD Pro running Linux in a non-default configuration – the BPF JIT is enabled – also lets a normal user process read from 4GB of kernel virtual memory.
- For Arm, Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73, and Cortex-A75 cores are affected by Spectre. Bear in mind Cortex-R series cores are for very specific and tightly controlled embedded environments, and are super unlikely to run untrusted code. To patch for Arm, apply the aforementioned KPTI fixes to your kernel, and/or recompile your code with new defenses described in the above-linked white paper.
- Googlers were able to test that an Arm Cortex-A57 was able to be exploited to read arbitrary data from memory via cache sniffing; the proof-of-concept worked just within one process, though. Google is confident ARM-powered Android devices running the latest security updates are protected due to measures to thwart exploitation attempts – specifically, access to high-precision timers needed in attacks is restricted. Further security patches, mitigations and updates for Google's products – including Chrome and ChromeOS – are listed here.
- Discovered and reported by these separate teams: Jann Horn (Google Project Zero); and Paul Kocher in collaboration with, in alphabetical order, Daniel Genkin (University of Pennsylvania and University of Maryland), Mike Hamburg (Rambus), Moritz Lipp (Graz University of Technology), and Yuval Yarom (University of Adelaide and Data61).
