Rowhammer is getting a lot of attention these days. Our researchers at Oneconsult are also investigating this new security issue and have discovered some interesting facts during the analysis.
What is Rowhammer? All common DRAM memory modules use memory cells which are arranged in a matrix configuration on the chips’ silicon surface. The technology used for (electrical charge) storage is highly volatile and has to be refreshed every couple of 10 milliseconds (hence the “D” for dynamic in the name). For every read or write operation an entire row of cells is processed and every cell in the row is newly charged or discharged in the process. Both operations lead to electrical fields and charges, which may influence the charge of cells in adjacent rows. These effects have been known for some time, but were only considered a reliability issue until now.
The recently published results show that these effects can be (more or less) reliably (ab)used to change normally inaccessible (or at least not writeable) memory and in turn circumvent various security mechanisms.
Even though the published results only describe attacks on Linux systems (where it was possible to gain full system access from a normal user process) there is no technical reason why such attacks should not work on any mother operating system or even allow escaping from hardware virtualization environments. While it is not entirely clear how the presented results can be transferred to other systems and situations, it is known that attacks only get better. This means, that the developments in this area should be closely monitored, especially as the possible countermeasures are complicated and can in part only be implemented via firmware or even hardware changes.
While some approaches how the presented attacks could be mitigated or detected are being discussed, such changes would have to be implemented at the operating system level and therefore take some time until they could be widely deployed.
Systems using ECC-RAM, which should precisely prevent random memory changes, should be much more resilient against these types of attacks, but since these correction mechanisms can only handle a small number of changed bits per 64 bit word and we have observed up to 89 changes in a 4KiB block, it is unclear if the number of acceptable bit errors may be higher at least in some cases.
During our own tests using the publically available tools (rowhammer_test and memtest86) we noticed two issues which we think did not get enough attention in the media so far:
- The usually recommended test methods are incomplete.
The commonly used tools “rowhammer_test” and “memtest86” (test 13) only implement single-sided rowhammering, but already the original blog post mentioned, that double-sided (using both, the row above and below the target row) rowhammering can produce additional error locations. During our own tests double-sided rowhammering produced bit errors on a machine which passed both single-sided tests.
The tool “double_sided_rowhammer” is also built by the provided make script for now and should be used for additional testing. Unfortunately, this tool is not very mature yet and may also report false negatives, but still raises confidence levels.
- The temperature of the memory modules is relevant.
This effect is also well known and has already been used (inverted) for the so called “cold-boot” attacks.
In short: The higher the temperature, the stronger and faster are the charge movements in the DRAM cells.
We could observe bit errors which were only present at higher system temperatures and vanished again when the system cooled down. We used CPU benchmarks to raise the temperature, but it should also be possible to use rowhammering or some other memory access pattern to increase the temperature in a specific chip area and provoke additional bit errors.
In summary, it seems that as with many new security issues, the actual impact and scale of the problem is not yet clear.
The systems with the greatest risk of being impacted by this problem are x86-architecture systems without ECC memory on which uncontrolled software (as x84/x86_64 instructions – including sandboxes) can be executed by third parties or people with restricted permissions.
Unfortunately, the only method currently known to reliably reduce the risk for such systems is to switch to ECC-capable hardware with ECC-RAM modules. However, using the available tools it is possible to get a first idea whether a system is more or less vulnerable (nevertheless, it should be noted that these tools should not be executed during normal operation, as they might cause arbitrary memory changes in the running software).
The research team of Oneconsult will continue to monitor the development and contribute to any solutions the best way possible.
[To be continued]