Security Bits – 30 June 2019

Followups

  • Facebook has replaced the infamous study app that breached Apple’s Enterprise Developer Program rules and got them into so much trouble a few months ago with a new app that is not side-loaded, is explicit in what it does, and is Android only (Editorial by Bart: I’m guessing they couldn’t get a useful spying app through Apple’s App Store review process) — techcrunch.com/…
  • We’ve mentioned before that as things stand, deleting an app with an active subscription on iOS will not terminate this subscription. This fact has been abused by apps with exorbitant subscription pricing. iOS 13 will change things for the better – when you delete an app with an active subscription, the OS will ask if you also want to end the subscription — www.macobserver.com/…

🧯Security Medium — RAMBleed

We’ve known about the RowHammer vulnerability for some time now. It allows attackers to alter the contents of another process’s memory if they can arrange to have memory they need to attack located physically next to memory they control on the computer’s RAM chips. The attack works by forcing the OS to read the attacking process’s RAM so often and frequently that the interference bleeds into the adjacent row on the RAM chip and alters its contents. The vulnerability affects the most commonly used types of RAM chips – DDR3 & DDR4 SDRAM.

Like with the Meltdown & Spectre-type attacks, RowHammer is not a big problem for consumers because the attacker has to be on your machine already. Basically, you need to be infected with malware to get RowHammered, and if there’s already malware on your machine, it can cause you more damage more easily by other means!

Again, like with Meltdown & Spectre, RowHammer is a big problem when you add virtualisation into the mix. Now, you have different VMs sharing the same RAM chips. Now, the malware can be running an entirely separate OS to the victim product. This would be utterly unacceptable in a cloud hosting environment!

However, in reality, RowHammer has not been much of a problem for cloud providers because they use high-end ECC RAM with has built-in error detection and correction, so any bits flipped by RowHammer get almost instantaneously flipped back to their original value, thwarting the attack!

In a true jiu-jitsu-style move, RAMBleed uses ECC to create a more dangerous variant of RowHammer that can’t alter data in a victim process, but can read it instead! That’s actually worse!

How does it work? Again, like with Meltdown & Spectre, RAMBleed is a side-channel attack. When ECC has to step in and fix a problem, it causes a detectable slow-down, so the attacking process can know when it caused a bit in the victim process to flip. Because of ECC, that flip is fixed before it can be read, so this might sound futile, but, there is one more subtle but important piece to the puzzle — there is an asymmetry between the probabilities of a bit being flipped from a one to a zero and a zero to a one.

RAMBleed slowly reads data in adjacent RAM by intentionally causing bit flips by RowHammering its own memory with different patterns of ones and zeros and measuring how often each pattern results in ECC having to correct a bit flip. When you have enough data on enough flips you can use some clever statistics to give you the probable value of the victim process’s memory.

The key point is that this attack is slow, hence the use of the word Bleed in the name. Since the famous Heartbleed vulnerability, it’s become common practice to append Bleed to the names of vulnerabilities that can be used to trickle data out slowly.

Because the attack is slow, it can’t be used to read values from memory that change often. It’s only useful against data that stays in memory for a long time. Unfortunately, some of the most valuable data of all sits in memory for days and weeks at a time — encryption keys! Full disk encryption and secure protocols like SSH need to keep their keys in RAM to function, and are usually running as long as the computer is.

The proof-of-concept for this attack was an exploit against open SSH, but that project has responded with an extremely clever solution — one that all other processes that keep sensitive data resident in RAM for long periods of time could also adopt.

The solution the OpenSSH team came up with sounds circular, but it’s not, and its actually gloriously ingenious! They encrypt their encryption key and keep the key to the encryption for their key in memory. How can that possibly work?

SSH keys are symmetric, that means they are part of a key-pair, and you can verify that your guess at the private half of the key is correct using the public key, which is not a secret. Because RAMBleed is probabilistic, it can’t give a perfect answer, just a range of probabilities, so to get an OpenSSH private key the attack calculates probable values for the private key, then tests each with the public key to figure out which one of their guesses is correct.

Symmetric encryption keys are not part of a keypair, so they have to be read perfectly to be usable. If you encrypt your private key with a long symmetric key, then the probability of RAMBleed reading your private key without getting a single bit wrong is vanishingly small to the point of being effectively impossible! So, by encrypting the SSH private key with a long symmetric key, the OpenSSH team have been able to protect their SSH implementation from RAMBleed at a software level.

Thankfully there are also hardware-level mitigations large cloud providers can use. Modern server-level CPUs support separate RAM encryption per-VM, so each VM’s RAM will be encrypted with a different key, and those keys are stored in secure enclaves on the CPU, so they’re never stored in RAM.

Links

Notable Security Updates

Notable News

Suggested Reading

Suggested Listening

Palate Cleansers

Note: When the textual description of a link is part of the link it is the title of the page being linked to, when the text describing a link is not part of the link it is a description written by Bart.

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top