A Google developer has discovered a new way that a 'Spectre'-style check can be used to attack any computer running any operating system, but the researchers describe the risks as low.
The flaw affects, discovered by Google Project Zero researchers, many chips from Intel, Advanced Micro Devices Inc and ARM Holdings.
The new category of speculative execution side channel vulnerability (Speculative Store Bypass or SSB) is closely related to the previously disclosed GPZ/Spectre variant 1 vulnerabilities.
The SSB, also known as Spectre Variant 4, uses speculative execution, a feature common to most modern processor architectures, to potentially expose certain kinds of data through a side channel. In this case, the researchers demonstrated Variant 4 in a language-based runtime environment. The most common use of runtimes, like JavaScript, is in web browsers.
Starting in January, most leading browser providers deployed mitigations for Variant 1 in their managed runtimes - mitigations that increase the difficulty of exploiting side channels in a web browser. These mitigations are also applicable to Variant 4 and available today.
Intel has already delivered the microcode update for Variant 4 in beta form to OEM system manufacturers and system software vendors, and expects it will be released into production BIOS and software updates over the coming weeks. In this configuration, Intel says it has observed no performance impact. If enabled, the company observed a performance impact of approximately 2 to 8 percent based on overall scores for benchmarks like SYSmark 2014 SE and SPEC integer rate on client1 and server2 test systems.
This same update also includes microcode that addresses Variant 3a (Rogue System Register Read), which was previously documented publicly by Arm in January.
Microsoft has released an advisory on the vulnerability and mitigation plans. According to the company, an attacker who has successfully exploited this vulnerability may be able to read privileged data across trust boundaries. Vulnerable code patterns in the operating system (OS) or in applications could allow an attacker to exploit this vulnerability. In the case of Just-in-Time (JIT) compilers, such as JavaScript JIT employed by modern web browsers, it may be possible for an attacker to supply JavaScript that produces native code that could give rise to an instance of the Speculative Store Bypass (SSB). However, Microsoft Edge, Internet Explorer, and other major browsers have taken steps to increase the difficulty of successfully creating a side channel.
AMD recommended mitigations for SSB are being provided by operating system updates back to the Family 15 processors ("Bulldozer" products). Microsoft is completing final testing and validation of AMD-specific updates for Windows client and server operating systems, which are expected to be released through their standard update process. Similarly, Linux distributors are developing operating system updates for SSB. AMD recommends checking with your OS provider for specific guidance on schedules.
Based on the difficulty to exploit the vulnerability, AMD and our ecosystem partners currently recommend using the default setting that maintains support for memory disambiguation.
AMD says it has not identified any AMD x86 products susceptible to the Variant 3a vulnerability in their analysis to-date.
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."
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."