Security Weekly 50: Updated Specter, Now With A Tasteful Record
We do not want to write about the Specter, but we have to: last week this is definitely the most important news. New versions of the Specter vulnerability, as well as the original ones, are shown by representatives of the academic community.
A researcher at the Massachusetts Institute of Technology Vladimir Kiryansky and independent expert Karl Waldspurger showed two new modifications of the Specter, named, without embarrassment and logos, Specter 1.1 and Specter 1.2 (news).
Important differences from the original Specter vulnerability in both cases are the use of the mechanism of speculative recording. In the case of Specter 1.1, the attack theoretically allows you to trigger (also speculative) buffer overflow and read the “forbidden” portion of the memory. Specter 1.2 provides the ability to overwrite the read-only information and theoretically allows an attack like sandbox escape, bypassing hardware security systems. For the detection of vulnerability, researchers received one hundred thousand dollars in the bug bounty program of Intel, and to date, it is one of the largest payments. Vulnerabilities are susceptible to the processors of Intel, ARM and, probably, AMD processors.
According to the authors, one of the key findings of the study is just a 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 that it opens the possibility of reading the memory area to which the attacking process should not have access.
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 mechanism of attack. This is the complexity of the hardware vulnerabilities of this class: too much should coincide so that the attack was successful. But when an attack occurs, in the worst case it allows you to steal valuable information, often without the ability even to post-factum to understand what exactly happened. Most importantly, the conditions for Specter 1.x can be created even in cases where a Specter 1.0 attack is not possible.
The researchers claim that there are no methods for detecting vulnerabilities of the Specter 1.1 type using code analysis or compilation tools. This vulnerability can be closed at the hardware level. It is also noted that the responsibility for reducing the risks of a successful attack type Specter often lies with software developers. Considering that for 30 years, since the first public demonstration of the attack with buffer overflow, the vulnerabilities in the software are much less, the authors predict the attacks on the mechanism of speculative execution of the code of “decades” of relevance.
Despite the foregoing, the authors believe that the combination of safe software and hardware with the benefits of protection from the mechanisms of speculative execution is theoretically possible. It remains to realize this in practice, that in the case of a class of vulnerabilities affecting iron, it can take years or decades. We wonder if the history of the Specter/Meltdown and their derivatives will lead to some serious change in the practices of software development and hardware?
