Updated: 20th March 2019
The Intel Spoiler vulnerability is not as bad as predicted. Software developers should continue to use safer code development practices.
After the disclosure earlier this month of this vulnerability Intel have provided further information on how it affects their microprocessors. They have clarified that the Spoiler exploit by itself does not reveal secret data and is not a speculative execution side channel method:
Other good news is that existing mitigations such as KPTI (kernel page table isolation) reduce the risk of leaking data across privilege levels. They again confirmed that side channel safe software development practices such as “ensuring execution time and control flows are identical regardless of secret data” will mitigate classic side channel methods enabled by the Spoiler exploit. Furthermore, they confirmed memory modules which are already mitigated against Rowhammer attacks remain protected against the Spoiler exploit.
Lastly AMD provided formal confirmation that their microprocessors are not vulnerable after preliminary findings suggested they weren’t vulnerable. AMD’s statement is available from this link.
Earlier this month a new vulnerability was disclosed in a research paper titled “Spoiler: Speculative load hazards boost Rowhammer and cache attacks”.
TL DR: Mitigating this newly disclosed vulnerability is the job of software developers to work around using safer code development practices. Mitigating this issue in hardware will take longer since current measures cause too much of a performance penalty.
Why should this vulnerability be considered important?
This Spoiler vulnerability can be used by attackers (who MUST have already compromised your system) to extract sensitive information from the systems memory (RAM). An attack does not require elevated privileges.
What CPUs (microprocessors / computer chips) are affected?
This vulnerability affects Intel processors only; first generation Intel Core (from early 2006) and later are affected. ARM and AMD processors are not affected. Any system with an Intel Core processor is affected regardless of the operating they are using namely Linux, Unix, Apple macOS and Windows can be all affected.
How does this vulnerability achieve the above results?
The security researchers who authored the paper found a vulnerability in the memory order buffer that can be used to gradually reveal information about the mappings of physical memory to non-privileged software processes (in other words; applications). This technique also affects virtual machine (VM) and sandboxed (defined) environments.
The technique works by understanding the relationship between virtual and physical memory by timing the speculative load and store operations to these areas while looking out for discrepancies which disclose the memory layout to you. With this information an attacker knows where to focus their efforts.
Intel’s proprietary implementation of the memory subsystem (memory disambiguation) is the root cause of the vulnerability. When a physical address conflict (the address/area is already in use) occurs, the algorithm leaks the access timings. The algorithm in the researcher’s words works as follows “Our algorithm, fills up the store buffer within the processors with addresses that have the same offset but they are in different virtual pages. Then, we issue a memory load that has the same offset similarly but from a different memory page and measure the time of the load. By iterating over a good number of virtual pages, the timing reveals information about the dependency resolution failures in multiple stages.”
How can this vulnerability be mitigated/patched?
This vulnerability lies within the memory disambiguation algorithm which won’t be trivial to resolve anytime soon. Since this vulnerability is not related to last years Spectre vulnerability; mitigations for that vulnerability don’t help here. Current Spoiler mitigations have too much of performance penalty. At this time, Intel has issued the following statement:
“Intel received notice of this research, and we expect that software can be protected against such issues by employing side channel safe development practices. This includes avoiding control flows that are dependent on the data of interest. We likewise expect that DRAM modules mitigated against Rowhammer style attacks remain protected. Protecting our customers and their data continues to be a critical priority for us and we appreciate the efforts of the security community for their ongoing research.”
The side channel safe development practices are linked to below: