Tag Archives: Rowhammer

RAMBleed: What you need to know

Yesterday; security researchers disclosed a vulnerability relating to how data is accessed after it is stored within computer memory modules eventually leading to partial data disclosure

================
TL DR:
================
This is a low severity (CVSS Base Score: 3.8) but notable vulnerability which cannot be exploited remotely. For organisations and customers; no action is required. It is up to software developers to use trusted execution environments (TEE) e.g. AMD SEV, ARM TrustZone or Intel SGX to protect important data or clear such data from memory after use. Some DDR4 modules are not vulnerable to Rowhammer.

================
How does this attack take place?
================
An attacker would first need to compromise your system and persuade you to run an application. Due to the physical effects of creating memory modules which are smaller and smaller the space between memory cells used to store data are subject to electrical interference. This can be exploited by an attacker by reading the data from a memory address of interest over and over again which eventually leads to data corruption causes the binary contents (0 or 1) used to store data to change/”flip” from 0 to 1 or vice versa.

This effect has been seen before in an attack dubbed “Rowhammer” in 2014. That attack can be mitigated by the use of memory modules that use ECC (Error Correction Code). However, this new technique RAMBleed cannot be mitigated by ECC (defined).

================
What must an attacker do to exploit this vulnerability?
================
An attacker must first map the memory which contains the data they wish to acquire. They can then work to control data each side in memory of the target data. Accessing this data over and over “hammers” the row with the data within it. If the data is 0, it will flip to 1 and if 1 becomes a zero (0). The attacker can then proceed to repeat this for one column down in the memory segment to obtain the next piece of target data. Researchers were able to obtain 3 to 4 bits (either 0 or 1) per second.

Researchers used this technique to obtain a 2048 bit OpenSSH key from the memory of a server. They did so by first using a technique they named “Frame Feng-Shui” that allows them to place the target data within a physical memory frame (area) of their choice in. The speed was 0.3 bits per second with an accuracy of 82%. By only obtaining some of the data and using a variant of the technique documented within the Heninger-Shacham algorithm they succeeded in obtaining the remainder of the key.

================
How can an organisation or a consumer/end-user defend against this attack?
================
Encrypted memory achieved by the use of trusted execution environments (TEEs) e.g. AMD Secure Encrypted Virtualization (SEV), ARM TrustZone or Intel Software Guard Extensions (SGX) will mitigate this attack since the attackers will obtain encrypted rather than ready to use/plain text data.

Alternatively; software developers can clear encryption keys or other sensitive data from memory after using it. Intel recommends it’s guidelines for resisting side-channel and timing side channel attackers:

A lesser known mitigation is the use of DDR4 memory modules that should disrupt the success of the Rowhammer attack. The Maximum Activation Count (MAC) of a memory row is not vulnerable to Rowhammer when the MAC has a value of “unlimited”.

This field exists within the SPD (Serial Presence Detect) technique of accessing memory. From the following page, many but not all of the examined DDR4 modules feature this setting. For example, my 4x 16 GB (64GB) Corsair Dominator Platinum PC4-21300 (CMX64GX4M4A2666C15) modules feature this setting and so appear not to be vulnerable to the Rowhammer technique. You can see this from the first attached screenshot (denoted by the value “Unlimited MAC”):

These screenshots were obtained from the RAMMon application available from PassMark.


Thank you.

Responding to the Intel Spoiler Vulnerability

====================
Updated: 20th March 2019
====================
TL DR:
The Intel Spoiler vulnerability is not as bad as predicted. Software developers should continue to use safer code development practices.

====================
After the disclosure earlier this month of this vulnerability Intel have provided further information on how it affects their microprocessors. They have clarified that the Spoiler exploit by itself does not reveal secret data and is not a speculative execution side channel method:

Other good news is that existing mitigations such as KPTI (kernel page table isolation) reduce the risk of leaking data across privilege levels. They again confirmed that side channel safe software development practices such as “ensuring execution time and control flows are identical regardless of secret data” will mitigate classic side channel methods enabled by the Spoiler exploit. Furthermore, they confirmed memory modules which are already mitigated against Rowhammer attacks remain protected against the Spoiler exploit.

Lastly AMD provided formal confirmation that their microprocessors are not vulnerable after preliminary findings suggested they weren’t vulnerable. AMD’s statement is available from this link.

Thank you.

====================
Original Post:
====================
Earlier this month a new vulnerability was disclosed in a research paper titled “Spoiler: Speculative load hazards boost Rowhammer and cache attacks”.

TL DR: Mitigating this newly disclosed vulnerability is the job of software developers to work around using safer code development practices. Mitigating this issue in hardware will take longer since current measures cause too much of a performance penalty.

Why should this vulnerability be considered important?
Using this new method; attackers are likely to find existing cache and memory Rowhammer attacks easier to carry out. In addition, JavaScript (defined) attacks which can take long periods of time may be shortened to mere seconds. The paper contains a cache prime and probe technique to leak sensitive data using JavaScript.

This Spoiler vulnerability can be used by attackers (who MUST have already compromised your system) to extract sensitive information from the systems memory (RAM). An attack does not require elevated privileges.

What CPUs (microprocessors / computer chips) are affected?
This vulnerability affects Intel processors only; first generation Intel Core (from early 2006) and later are affected. ARM and AMD processors are not affected. Any system with an Intel Core processor is affected regardless of the operating they are using namely Linux, Unix, Apple macOS and Windows can be all affected.

How does this vulnerability achieve the above results?
The security researchers who authored the paper found a vulnerability in the memory order buffer that can be used to gradually reveal information about the mappings of physical memory to non-privileged software processes (in other words; applications). This technique also affects virtual machine (VM) and sandboxed (defined) environments.

The technique works by understanding the relationship between virtual and physical memory by timing the speculative load and store operations to these areas while looking out for discrepancies which disclose the memory layout to you. With this information an attacker knows where to focus their efforts.

Intel’s proprietary implementation of the memory subsystem (memory disambiguation) is the root cause of the vulnerability. When a physical address conflict (the address/area is already in use) occurs, the algorithm leaks the access timings. The algorithm in the researcher’s words works as follows “Our algorithm, fills up the store buffer within the processors with addresses that have the same offset but they are in different virtual pages. Then, we issue a memory load that has the same offset similarly but from a different memory page and measure the time of the load. By iterating over a good number of virtual pages, the timing reveals information about the dependency resolution failures in multiple stages.”

How can this vulnerability be mitigated/patched?
This vulnerability lies within the memory disambiguation algorithm which won’t be trivial to resolve anytime soon. Since this vulnerability is not related to last years Spectre vulnerability; mitigations for that vulnerability don’t help here. Current Spoiler mitigations have too much of performance penalty. At this time, Intel has issued the following statement:

“Intel received notice of this research, and we expect that software can be protected against such issues by employing side channel safe development practices. This includes avoiding control flows that are dependent on the data of interest. We likewise expect that DRAM modules mitigated against Rowhammer style attacks remain protected. Protecting our customers and their data continues to be a critical priority for us and we appreciate the efforts of the security community for their ongoing research.”

The side channel safe development practices are linked to below:

Software Guidance for Security Advisories

Addressing Hardware Vulnerabilities

Thank you.