Is it possible that your processor speed is precisely what's compromising your security? To understand how processors achieve their speed , we must consider that they work by "predicting the future"... No, they're not magic or have a tiny crystal ball...
The way processors work is that instead of waiting to see which path a program will take, the chip predicts the likely route and anticipates it. If the prediction is incorrect, the work is discarded, but traces remain in memory. This is where Spectre comes in , one of the most significant vulnerabilities discovered in recent years. Since its discovery, attackers have learned how to read these traces, creating increasingly sophisticated variants; TONTOU is one of these new vulnerabilities.
MIT researchers have discovered TONTOU (Time-of-Neutralization to Time-of-Use), a sophisticated new technique for exploiting Spectre v2 vulnerabilities , allowing kernel memory to be read from user space.
Although manufacturers and developers have designed various protection mechanisms against predictive attacks for years, attackers have managed to discover new routes, and this new CSAIL study demonstrates how to bypass these protections.
Researchers discovered that there is an unavoidable time gap between the moment the buffer is cleared and the instant the predictions are used, and it is in this small gap that code (sometimes just a handful of instructions) is injected through system interrupts, making it possible to re-contaminate the hardware and extract critical data.
Regarding the Attack: Disruptions and the Breach in Safe-RET
AMD has a defense against SRSO (Speculative Return Stack Overflow) vulnerabilities called Saferet, which cleans the prediction machinery immediately before each use. This leaves a window of vulnerability that can be exploited in a few tens of nanoseconds. To attack such a small window, researchers developed a technique they called Interrupt Injection.
Processors constantly pause their tasks to handle interrupts, and common programs can configure these timers . With this in mind, researchers precisely adjusted a timer and, using a technique to slow down the CPU, caused the processor to be interrupted at exactly the wrong moment . During this interrupt, an attacker can force a large number of calls to be executed, overflowing the address stack. When the erroneous execution ends, the processor discards the process, but the accessed data remains in the shared caches , from where it can be extracted by analyzing access times.
Password Extraction and Testing on Real Systems
To demonstrate the severity of TONTOU, the team built a working exploit on an AMD system running a current Linux kernel. The first hurdle was bypassing the defense that randomizes the operating system's position in memory, which they managed to do in ten attempts, taking about nine minutes per test.
Subsequently, they demonstrated a local attack as an unprivileged user to determine the root password hash, successfully extracting data at a rate of 5.47 bytes per second with 91.97% accuracy. In 50% of the tests (which averaged 18 minutes), they successfully detected and extracted the contents of the password file. While this is a slow speed, it is more than sufficient to critically compromise a server.
Impact on Intel, AMD, and the mitigation patch
The team tested four generations of Intel and AMD processors, achieving prediction failures on both architectures. While the technique proved viable on AMD's Zen 1 to 4 families , on Intel chips the attack bypassed two different protections , although inconsistent behavior was observed between different Intel generations, suggesting that the nominal defenses are implemented differently in the hardware.
As a solution, the researchers suggest clearing the prediction machinery a second time after the interrupt finishes. While this measure seems viable for AMD, it could be counterproductive for Intel, since the attack relies on the interrupt leaving a consistent state and could make the attack more reliable.
The researchers notified AMD and Intel in early February and the Linux kernel maintainers in March. As a result, the code blocking to mitigate the vulnerability was integrated into the Linux kernel on August 5th.
Finally, if you are interested in learning more, you can find the details at the following link.