Most of the security flaws and problems that get attention in the community are fundamentally software-based. It’s not impossible to find a hardware bug.
Here’s how Rowhammer works: Recent research has shown that repeatedly accessing the same memory blocks over and over can cause a bit flip in other DRAM locations. These early attacks, however, required executing native code and relied on special instructions. A recent Chrome patch eliminated support for some of these instructions, which was thought to cause the problem.
What new research has demonstrated, however, is that the code doesn’t need to be native — it can be written in JavaScript. More than that, however, executing Rowhammer doesn’t require local program execution privileges, which used to be the case. Instead, the code can theoretically be executed via JavaScript, which means it can be served up by web browsers rather than relying on direct system access.
At a high level, DRAM is organized into matrices of rows and columns. Conceptually, the arrangement is similar to a spreadsheet, and the exact cell to be read or written is located by a combined column and row address. Because it takes electrical current to read and write data from memory, performing operations on DRAM cells necessarily requires an electrical current. That current can have an impact on adjacent cells, and the chance that a DRAM or write has an impact on a nearby cell has only increased as cells have transitioned to smaller geometries and become more tightly packed.
By rapidly activating an aggressor row, a hostile program can cause adjacent DRAM cells to flip their values (the victim rows). In the diagram above, the aggressor row is the purple row, while the two victim rows are shown in yellow. If the chips aren’t quickly refreshed by the system, a disturbance error occurs, which means the values in those particular DRAM cells changes. There’s also a double-sided Rowhammer attack, in which the two yellow rows are used to launch an attack against the purple row — this method has a considerably higher chance of success.
One of the standard methods of protecting an operating system is to prevent processes from accessing memory that hasn’t been assigned to them. Your Chrome.exe or Firefox.exe process can’t just go snooping around in a game you’re playing, or even in each other’s memory locations. That’s the kind of trick that leads to hard locks and terminal errors in short order, particularly if one process overwrites values in another processes’ memory space.
