So what are the keys to your castle? Well, often it is your SSH keys, as these are the ones that are used to gain access to your cloud and remote systems. In fact, if we lose our private keys, we can compromise the whole of our infrastructure, and, in fact, our business.
Now a new memory-based vulnerability has been found which can extract these keys: RAMBleed [paper]. With new vulnerability (CVE-2019–0174) is based on the Rowhammer flaw and where cells in memory leak charge between each other. In this way it is possible to set bits in the memory by setting memory cells that are nearby to the target storage elements. It is caused by the ever increasing density of DRAM memory cells (especially with DDR3 and DDR4 SDRAM memory), and where an attacker can analyse the layout of the memory and compromise it with predefined memory patterns.
Basically a single bit of memory is created with a tiny capacitor (which stores charge — for a 1, or does not store charge — for a 0). If these capacitors are located physically near to other cells, the charge from them to leak to neighboring ones. So, in the following diagram, we can see the target cell could be changed by the cells which surround it:
In this way, we could setup 1’s around the cell, and, if the target was a ‘0’ it would flip the bit for the target cell to be a ‘1’ (the charge would leak from the other cells surrounding it). If it was already a ‘1’ it would stay the same.
In the original Rowhammer paper by Kim et al in 2014 [here], the researchers continually read from the same address in memory and managed to corrupt data within nearby addresses. They managed — with as little as 139,000 accesses — to produce errors in 110 out of 129 of the DRAM models that they tested.
With RAMBleed, we now see the opportunity to not just change the contents of the memory, but to now read from it. This provides the opportunity of creating a side channel into the memory, and overcome its protections, and where it does not corrupt the running memory. The key focus is on the bits that are physically directly above and below the protected target bit.
For this Eve — the attacker — produces a template of the memory and in order to find a flippable bit. She does this by finding a bit which has the same offset in a memory page as the protected target bit — this then sits within the Secret (S) area. She then produces memory rows of size 4KB:
Row Activation Page (A0) [4KB] | Secret (S) [4KB]
Unused [4KB] | Sampling Page (A1) [4KB]
Row Activation Page (A2) [4KB] | Secret (S) [4KB]
The researchers defined this a Frame Feng Shui. With this, Eve has control over the 4KB row activation pages (A0 and A2), and which are beside the secret (S). She then hammers the middle row, and the target bit will eventually reveal itself in the middle row (A1). If the bit is a zero, it is flippable, and the bit above and below are set of a 0 (0–1–0). If it is a one, it not not flippable. Eve can then discover the content of the secret bit by testing to see if the bits are flippable or not. Eve then moves onto the next target bit, and can thus reveal the contents of a secret. The researchers were able to get a read back speed of around 3–4 bits per second, and thus for a 2,048-bit (2K) RSA private key it would take around eight minutes to discover it.
In order to demonstrate the attack, the research team were able to discover a 2K RSA key from a server running OpenSSH 7.9, and had a success rate of over 80%. As they had discovered most of the bits in the key, the used a variation of the Heninger-Shacham method to discover the full key details.
To guard against this attack, we can use:
- DDR4 DRAM modules with targeted row refresh (TRR) enabled. Generally DDR4 memory module are mainly resistant against Rowhammer attacks.
- Run systems within a trusted execution environment (TEEs), such as Software Guard Extensions (SGX) within Intel architectures. This then creates trusted enclaves for the encryption processes to take place.
- Flush encryption keys from memory once it has been used.
Our model of our computer systems goes back to the 1970s, and where security was an afterthought. We thus need to re-think trust, and defining trust at the lowest layers — the physical layers — is key to properly creating trusted environments. The leakage of a private key is one of the most expensive threats to deal with, so we need to make sure our private keys are never revealed. For developers, the advice is to flush that memory after the key has been used, and for architects, it is for us to build trusted execution environments.