Search the Community

Rowhammer: NaCl Sandbox Escape PoC Rowhammer: Linux Kernel Privilege Escalation PoC Software, from web apps, to operating systems to firmware, has been abused and exploited every which way from Sunday for decades by both researchers and attackers. Now, it is hardware’s turn in the spotlight, as researchers have published details of a new method for exploiting a problem with some DRAM memory devices that can allow attackers to get low-level access to target machines. The problem is being called “rowhammer”, as it’s a method for repeatedly hammering on rows of cells of memory in DRAM devices to induce cells to flip from one state to another. Using a new technique to exploit the rowhammer issue, researchers at Google were able to produce these bit flips in cells and gain kernel-level privileges. Security researchers say the technique is some of the more important work done on exploitation in recent years and could affect a huge number of laptops and desktop machines. “[it] is a brilliant attack and because it’s a hardware flaw, there are really no ways to patch it,” said Alfredo Ortega, a longtime security researcher and co-founder of Groundworks Technologies. Researcher Mark Seaborn on Monday published a detailed technical explanation of techniques to exploit the rowhammer issue, which was described earlier in an academic paper by researchers from Intel and Carnegie Mellon University. The basic concept behind rowhammer relies on the fact that the cells of memory on DRAM devices have become closer and closer together over time, meaning that it has become more difficult to prevent electrons from jumping from one cell to another. By accessing target cells in DRAM over and over again, an attacker can disturb a cell adjacent to the target cells, causing it to “bit flip” under some circumstances. “‘Rowhammer’ is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process,” Seaborn wrote in his post. “When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory.” Seaborn tested his technique on 29 different machines with several different CPUs and DRAM from several vendors and observed a bit flip in 15 cases. However, he stressed that the lack of an observed bit flip does not mean that the DRAM isn’t necessarily exploitable. “While an absence of bit flips during testing on a given machine does not automatically imply safety, it does provide some baseline assurance that causing bit flips is at least difficult on that machine,” Seaborn said. Ortega said that the new technique is effective thanks to the way that DRAM devices are designed now. “Modern memory is flawed, vendors cut corners a lot to save power and make cheap tiny chips, so if you access too quickly a section of it, or if you turn on and off a memory cell too quickly, the adjacent memory cells will also be affected,’ he said. “The trick is to find a memory cell that stores something important and that you cannot access for security reasons, for example a memory cell storing a password, or file permissions, and then flip a cell next to it. Eventually the memory cell will flip, even if you don’t have access to it.” Mitigating rowhammer attacks is possible, Seaborn said. For example, manufacturers can make sure that when a system refreshes DRAM memory that it doesn’t activate a given row too often without also refreshing nearby rows. The rowhammer issue is not unknown to DRAM manufacturers, as some of them may already have implemented some mitigations. “Looking backward, had there been more public disclosures about the rowhammer problem, it might have been identified as an exploitable security issue sooner. It appears that vendors have known about rowhammer for a while, as shown by the presence of rowhammer mitigations in LPDDR4. It may be that vendors only considered rowhammer to be a reliability problem,” Seaborn said. Security researcher Dan Kaminsky, chief scientist of White Ops, said that the attack is effective in a surprising number of cases. “This sort of bug fills memory — the grand collection of buckets in your computer — with lots and lots of areas where checks for God like power depend on the bucket being empty. Then it shakes specially chosen buckets — ‘aggressor buckets’ — to try to leak a 1 into all those 0’s. And on a surprising amount of hardware, it works,” Kaminsky said via email. However, one good defense against the attack is the use of ECC memory, which has extra bits to help correct errors. ECC is more expensive, though, and mainly is used in servers rather than laptops and desktops, said researcher Robert Graham of Errata Security. “The biggest threat at the moment appears to be to desktops/laptops, because they have neither ECC memory nor virtual machines. In particular, there seems to be a danger with Google’s native client (NaCl) code execution. This a clever sandbox that allows the running of native code within the Chrome browser, so that web pages can run software as fast as native software on the system. This memory corruption defeats one level of protection in NaCl. Nobody has yet demonstrated how to use this technique in practice to fully defeat NaCl, but it’s likely somebody will discover a way eventually,” Graham said. The new techniques, Seaborn said, are a good example of why manufacturers and researchers should be paying close attention to hardware vulnerabilities. “History has shown that issues that are thought to be “only” reliability issues often have significant security implications, and the rowhammer problem is a good example of this. Many layers of software security rest on the assumption the contents of memory locations don’t change unless the locations are written to,” he said. “Though the industry is less accustomed to hardware bugs than to software bugs, we would like to encourage hardware vendors to take the same approach: thoroughly analyse the security impact of ‘reliability’ issues, provide explanations of impact, offer mitigation strategies and — when possible — supply firmware or BIOS updates. Such discussion will lead to more secure hardware, which will benefit all users.” Source