Security Week 24: Rowhammer in Android and the complexity of hardware vulnerabilities

It goes something like this with the Rowhammer class vulnerabilities. Four years ago, it was discovered that it was possible in principle to change the “neighboring” bits in the RAM module by regular read / write operations. Since then, new research has emerged showing how to apply this feature of tightly packed memory chips to practical attacks. Last week, a team of scientists from different countries showed a practical attack on Android smartphones RAMpage ( news , research ). How dangerous is this attack? Let's try to figure it out (spoiler: unclear for now).
I recall the attack Rowhammer uses the fundamental features of memory chips. Specifically, the change in charge when writing to a specific cell (more precisely, a number of cells) affects the neighboring cells (rows), too. This is usually not a problem, since at certain intervals the charges in all cells are updated. But if you often read and write a lot (tens and hundreds of thousands of times), you can change the value in memory cells to which you initially did not have access (everything written above is a vulgar simplification bordering on crime, and the truth is only in the original scientific work). It is not easy to adapt this memory feature for any real attack: you need the right combination of system access rights, code location in memory, direct memory access without caching, and so on and so forth. Not immediately, but in four years there were quite a few examples of such combinations, and Rowhammer turned from a nice theory into a harsh practice.

When you need a picture about computers, hammers and security
I will not even try to retell in simple terms a RAMpage attack. This attack bypasses the patches embedded in Android after the discovery (approximately by the same group of researchers) of the Drammer attack in 2016. A combination of several previously known methods that provide direct access to RAM in the right place., and the features of the modern version of Android (the experiment used the LG G4 phone with Android 7.1.1) allowed to get the superuser's rights on the fully patched phone.
What is uncharacteristic for research on a new vulnerability, the authors of RAMPage also offer a way to close the vulnerability, and with a very slight drop in performance (according to Google, the drop is still significant there). Moreover, the mitigation (she also came up with a name - GuardION) allows you to turn back the optimization turned off in Android after a previous study.

In the best tradition of modern vulnerability marketing vulnerability (and patch) made the site and logos. But since they are scientists, the FAQ on this site is extremely honest: "No, this is not Specter, not even close by." "No, we will not show you the PoC." “We don’t know if your phone is susceptible
What, if expressed in ordinary Russian, happened? The researchers slightly raised the bar of the practicality of another attack that uses hardware vulnerabilities. It does not yet apply (and is unlikely to be) crime, and generally it’s not a close path from the state of “received root in the laboratory” to “we can attack a significant number of devices of real users”. Google is aware, and somehow at least in new versions of Android keeps the problem under control. Such studies require a lot of time, and the danger lies in the possible abrupt transition from quantity (man-hours spent) to quality. Namely: the appearance of some relatively easy (at least as Meltdown) exploited hole, which can be closed either by buying a new device, or by a drop in productivity by several times.
However, the sentence above is already a careless assumption ( but the author of the text is possible, he is not a scientist ). Meanwhile, another group of researchers seemed to have found another hardware vulnerability, this time in the hyperthreading function in Intel processors. Moreover, the vulnerability was applied to steal the encryption key from a process running in the neighboring "thread" of the same kernel. And OpenBSD maintainers were so impressed with the results that they decided to turn off support for the processor functionality in the distribution kit completely (with obvious consequences for performance). The research work is scheduled for publication at the Black Hat conference in August. We continue the observation.
Disclaimer: