Security Week 26: Specter updated, now tastefully written

I do not want to write about Specter, but it’s necessary: ​​last week it was definitely the most important news. The new Specter vulnerability options, like the original ones, are shown by representatives of the academic community. Researcher at the Massachusetts Institute of Technology Vladimir Kiryansky and independent expert Karl Waldspurger showed two new Specter modifications, named, without a hitch and logo, Specter 1.1 and Specter 1.2 ( news , original scientific work ).

Important differences from Specter’s initial vulnerability in both cases are the use of the speculative recording mechanism. In the case of Specter 1.1, the attack theoretically allows you to call (also speculative) buffer overflow and read the "forbidden" memory. Specter 1.2 provides the ability to rewrite read-only information and theoretically allows an attack of the sanbox escape type, bypassing the hardware protection systems. For the discovery of vulnerabilities, researchers have received one hundred thousand dollars as part of Intel's bug bounty program, and today it is one of the largest payments. Vulnerabilities are affected by Intel, ARM processors and, probably, AMD processors.

According to the authors, one of the key findings of the study is the new concept of “speculative buffer overflow”. Overflow causes a write operation - performed at the right time and in the right place, it is inevitably discarded as incorrect, but even before it opens the possibility of reading a memory area to which the attacking process should not have access.

The key illustration of the idea: bypass protection (bounds check) not with a read operation, as in the original Specter, but with a write operation.

The list of conditions under which one of the new vulnerabilities can be implemented in practice, takes almost more space than the description of the attack mechanism. Therein lies the complexity of the hardware vulnerabilities of this class: too much has to match for an attack to be successful. But when an attack occurs, in the worst case, it allows you to steal valuable information, often without the possibility of even post-factum understanding what exactly happened. The most important thing: the conditions for Specter 1.x can be created even in cases where the Specter 1.0 attack is impossible.

The researchers claim that there are no methods for detecting Specter 1.1 vulnerabilities using code analysis or compilation tools. At the same time, this vulnerability can be closed at the iron level. It is also noted that responsibility for reducing the risks of a successful Specter attack is often placed on software developers. Considering that in the 30 years since the first public demonstration of the buffer overflow attack, there are no fewer vulnerabilities in the software, the authors predict attacks against the speculative execution of the decade code of relevance.

Notwithstanding the foregoing, the authors believe that the combination of secure software and hardware with the advantages of protection against speculative execution mechanisms is theoretically possible. It remains to realize this in practice, which in the case of a class of vulnerabilities affecting iron, can take either years, or decades. I wonder if the history of Specter / Meltdown and their derivatives will be a step towards some serious change in the practices of software development and hardware?

Disclaimer: The opinions expressed in this digest may not always coincide with the official position of Kaspersky Lab. Dear editors generally recommend to treat any opinions with healthy skepticism.