Spectre Chip Security Vulnerability Strikes Again
After the first-wave of Spectre and Meltdown attacks were conquered, people relaxed. That was a mistake.
Since the CPU vulnerabilities Spectre and Meltdown showed an entirely new way to attack systems, security experts knew it was only a matter of time until new assault methods would be found.
They’ve been found.
Jann Horn, a Google Project Zero security researcher, discovered this not long after the first Spectre holes were patched. Horn found a new way to attack microprocessors, which use Spectre-like speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known. With this, and armed with the right code, a local user can pull data from a system using a side-channel analysis.
This is far more than an Intel problem. It also affects x86 (Intel and AMD chipsets), POWER 8, POWER 9, System z, and a few ARM processors. In short, it could allow unauthorized read access to memory on almost any 21st century processor.
The Common Vulnerability and Exposures (CVE) number for this security problem is CVE-2018-3639.
Intel calls this a Speculative Store Bypass (SSB), also known as Spectre Variant 4. Unlike the bug discovered by Yuriy Bulygin, the former head of Intel’s advanced threat team, who showed that the older Spectre CPU flaws could be used to break into the Intel x86 systems’ System Management Mode (SMM), SBB is a new method.
Another new but less dangerous Spectre-style security hole is CVE-2018-3640, aka Rogue System Register Read (RSRE), or Spectre Variant 3a. This one can impact systems with microprocessors utilizing speculative execution that perform speculative reads of system registers.
With this, local users may be able to get unauthorized disclosure of system parameters via a side-channel analysis.
External attacks, via a web browser processing a malicious payload, are less likely with both these problems according to Intel. That’s because, Intel states, “Most leading browser providers have recently deployed mitigations in their Managed Runtimes — mitigations that substantially increase the difficulty of exploiting side channels in a modern web browser. These techniques would likewise increase the difficulty of exploiting a side channel in a browser based on SSB.”
To fix the problem, Intel has released beta microcode updates to operating system vendors, equipment manufacturers, and other ecosystem partners adding support for Speculative Store Bypass Disable (SSBD). SSBD provides additional protection by blocking Speculative Store Bypass from occurring. Intel hopes most major operating system and hypervisors will add support for Speculative Store Bypass Disable (SSBD) starting as early as May 21, 2018.
This update also addresses Rogue System Register Read (RSRR). It does this by ensuring that RDMSR instructions will not speculatively return data under certain conditions. No operating system or hypervisor changes are required to support this patch.
AMD and ARM have also both addressed these problems. At this time, Microsoft states, “We are not aware of any exploitable code patterns of this vulnerability class in our software or cloud service infrastructure, but we are continuing to investigate.”
Red Hat, however, admited that this vulnerability could be used against Linux systems. Red Hat suggested, “To fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers, but at a future time Red Hat will release the tested and signed updates as we receive them.”
Other operating system vendors will be issuing patches shortly.
How bad is it? Red Hat rates it as Important. That seems about right to me. It would take a local user and some effort to exploit this hole, but it’s perfectly doable.
It’s worth keeping in mind that a “local” user doesn’t have to be someone logged into a server. For example, who’s the “local” user on a container?
Red Hat states, “Every Linux container includes a Linux base layer. For these containers to be used in production environments, it is important that this content is free from known vulnerabilities. If the container includes a kernel, virtualization components, or other components listed below, they should be updated. Once updated, there are no container-specific related actions that need to be taken unless the container has dependencies upon or includes the affected packages. The following files must be updated: kernel, kernel-rt,libvirt, qemu-kvm-rhev, openjdk, microcode_clt, and linux_firmware.”
As Chris Robinson, Red Hat’s Manager of Product Security Assurance, said, “This vulnerability (CVE-2018-3639) is the latest example of flaws discovered by a recent focus on the fundamental elements of modern computing, vulnerabilities that cross numerous hardware and software platforms. While the flaws require a sophisticated attacker to exploit, customers should act quickly to apply both hardware and software updates to reduce the risk of exploitation.”
Robinson’s right. When the patches are available, deploy them.
Related Stories:
READ MORE HERE
