A team of researchers has proposed two software-based methods that could be used to mitigate Rowhammer, a type of attack that exploits weaknesses in the design of dynamic random-access memory (DRAM).
Rowhammer attacks are possible due to increasing DRAM density, which has led to memory cells being physically smaller and closer together. If a row is accessed repeatedly, it causes bit flips in adjacent memory rows.
The first working privilege escalation exploits leveraging Rowhammer were disclosed by Google researchers in March 2015. Experts later created a JavaScript implementation, and they recently demonstrated that the attack can even be used to root some Android devices.
Rowhammer attacks are not easy to mitigate, particularly using software. The most efficient mitigation involves redesigning DRAM modules. However, researchers from the Technische Universität Darmstadt and the University of Duisburg-Essen in Germany have now come up with what they call “practical and generic software-only defenses.”
The first method, dubbed B-CATT, doesn’t require any changes to the OS and it can be used on all x86 systems. B-CATT is a bootloader extension that locates and disables vulnerable physical memory. Vulnerable memory addresses are identified using existing Rowhammer exploitation tools. Since OSs are designed to handle unavailable memory regions, B-CATT should not break any system functionality, researchers said.
The second mitigation, G-CATT (Generic-CATT), aims to prevent bit flips from affecting memory locations belonging to high-privileged security domains, such as the kernel and co-located virtual machines. It does this by ensuring that memory between the row controlled by the attacker and the row storing the targeted data are separated by at least one row.
“Our extensive evaluation shows that both mitigation schemes can stop available real-world Rowhammer attacks, impose virtually no run-time overhead for common user and kernel benchmarks as well as commonly used applications, and do not affect the stability of the overall system,” the researchers said.
Experts comment on the B-CATT and G-CATT mitigations
At the recent 2016 Black Hat Europe conference, Anders Fogh, principal malware analyst at G DATA Advanced Analytics, and Michael Schwarz, a Ph.D. student at the Graz University of Technology in Austria, detailed a new DRAM attack and demonstrated an improvement to Rowhammer.
Contacted by SecurityWeek, both Schwartz and Fogh agreed that the paper describing software defenses for Rowhammer attacks is an important contribution, but they believe there are several issues that still need to be addressed.
“I haven't read the paper in detail yet, but as far as I've seen it, it does not break Rowhammer completely, it only prevents the strong double-sided Rowhammer,” Schwartz said. “Furthermore, an attack from one application to another is also not prevented, only from user applications to the kernel.”
Schwartz believes that while these mitigations make it more difficult to mount successful Rowhammer attacks, such attacks are still possible.
Fogh shared a more detailed analysis of the paper, but pointed out that some of his comments are speculative given the short timeframe.
The researcher believes the B-CATT idea is “fairly good,” but there are some weak points, including that the prevalence of bit flips is underestimated. Fogh said the following about this method:
1) Might black list too much memory
a. Kim et al. mention the idea and concluded that it’s likely to be prohibitively expensive in terms of blacklisted memory – though the data they present does not allow strong conclusions. I think Kim et al. is close to the truth if we want to protect the entire population of DRAM, but for moderately vulnerable DRAM this solution could make a serious dent in the attack surface;
b. The authors use a sample of 3 systems for their evaluation, which has a large variance of 133 vs. 23 affected page frames. Consequently, their result is unlikely to say much about the “population of DRAM”;
c. I’m not aware of other sources on the number of affected page frames, but we do have a solid indication of a large variance. For instance, Kim et al. reported upwards of 105 errors in 109 cells on some DIMMs. That’s more than 6 million bit flips in an 8Gb DIMM, which should be significantly more than 133 page frames. Another data point is that the row hammer patient 0 (the first computer where an exploit was running) is lovingly called “Flippy the laptop” by Thomas Dullien;
d. Bhattacharya et al. actually does target row hammering – that is on a known, fixed location. That speaks for that vulnerable page frames is significantly more common that the 0,0something% that the paper suggests.
2) The methodology of finding bit flips
a. The authors mention “On the other hand, it’s not yet known whether memory vulnerable to bit flip change over time or under different experiment conditions (e.g. temperature, methodology to identify bit flips)”;
b. Unfortunately, Kim et al. concludes that temperature does matter (though not much);
c. Mark Lanteigne shows that data patterns matter a lot and coins the term “killer data patterns” and speculates “We believe that there is likely a killer data pattern specific and unique to every system, but that discovering a single pattern to find more issues on”;
d. Mark Lanteigne shows that bit flips are best found by local hammering as opposed to the global approach by Seaborn and Dullien, which this paper adopts. Also, Mark Lanteigne shows that multi-core hamming outperforms the single-core hammering of Seaborn and Dullien;
e. There are good reasons to think that DRAM ages and DRAM can become vulnerable with age. And potentially even be made to age artificially. I speculated on the subject in October last year. I did some experiments on the subject with inconclusive results, however Al-Ars provides some data from DRAM from 2005. The author notices this and says that regular rescans would be required – certainly a significant overhead and associated downtime on a system. With an evil race condition between updating and getting pwned.
Section one essentially adds up to “We need more research and despite the result in this paper, in my opinion, we are likely to end up with unsatisfying results for some DIMMs”. Section two is not an argument that the B-CATT is broken, rather an argument that the issue is more complex than it first looks. Again, a call for more research seems prudent, but there is also this nagging feeling that building a truly safe solution across systems and use cases may not be possible. Essentially, even with B-CATT running, we may still run into situations where bit flips are possible.
As for G-CATT, Fogh pointed out that the idea is not new – it was described last year at the Chaos Communication Congress by Daniel Gruss and Clementiné Maurice. While the B-CATT mitigation is independent of the work presented by Fogh and Schwartz at Black Hat Europe, G-CATT “draws heavily” on their research. According to Fogh,
the method will be really effective, but it comes at a price. The memory allocation process loses a degree of freedom and becomes more rigid. With just a few security domains, say a single-user computer with just kernel protected from user mode, this is probably not going to be a big factor. It gets much much worse in say a 64-user cloud computer, which each has a kernel and it’s consequently 128 different security domains. Especially if physical memory requirements of the clients change often, this will become a problem.
The model they suggest for a per process protection would require blocking no less than 12 pages to allocate a single page on skylake, when it cannot be allocate next to existing allocations. That’s a fairly big overhead. Allocating next to existing allocations however will come at a performance penalty through lacking bank parallelism for that process.
They present no test data on their per process model. There is also the problem of sandboxes within processes, such as the chrome NaCl sandbox. Here the very code you are protecting in a security domain is trying to modify itself to break out – that seems like a particularly nasty scenario. I’m skeptical that such a problem can easily be solved at a reasonable overhead even with a custom “malloc” function.
No comments:
Post a Comment