Hardware Bit-Flipping Attacks in Practice

A year and a half ago, I wrote about hardware bit-flipping attacks, which were then largely theoretical. Now, they can be used to root Android phones:

The breakthrough has the potential to make millions of Android phones vulnerable, at least until a security fix is available, to a new form of attack that seizes control of core parts of the operating system and neuters key security defenses. Equally important, it demonstrates that the new class of exploit, dubbed Rowhammer, can have malicious and far-reaching effects on a much wider number of devices than was previously known, including those running ARM chips.

Previously, some experts believed Rowhammer attacks that altered specific pieces of security-sensitive data weren’t reliable enough to pose a viable threat because exploits depended on chance hardware faults or advanced memory-management features that could be easily adapted to repel the attacks. But the new proof-of-concept attack developed by an international team of academic researchers is challenging those assumptions.

An app containing the researchers’ rooting exploit requires no user permissions and doesn’t rely on any vulnerability in Android to work. Instead, their attack exploits a hardware vulnerability, using a Rowhammer exploit that alters crucial bits of data in a way that completely roots name brand Android devices from LG, Motorola, Samsung, OnePlus, and possibly other manufacturers.

[…]

Drammer was devised by many of the same researchers behind Flip Feng Shui, and it adopts many of the same approaches. Still, it represents a significant improvement over Flip Feng Shui because it’s able to alter specific pieces of sensitive-security data using standard memory management interfaces built into the Android OS. Using crucial information about the layout of Android memory chips gleaned from a side channel the researchers discovered in ARM processors, Drammer is able to carry out what the researchers call a deterministic attack, meaning one that can reliably target security-sensitive data. The susceptibility of Android devices to Rowhammer exploits likely signals a similar vulnerability in memory chips used in iPhones and other mobile devices as well.

Here’s the paper.

And here’s the project’s website.

Tags: academic papers, Android, exploits, hacking, phones

Posted on October 27, 2016 at 2:23 PM • 16 Comments

Comments

Otherwise • October 27, 2016 3:06 PM

Memory got cheap and plentiful, software expanded to fill it up, and manufacturers scoffed at measures like ECC for consumer devices. As bits got cheaper, so did the difference between true and false.

Clive Robinson • October 27, 2016 4:03 PM

“And the walls came tumbling down…”

The trick with rowhammer is in fact that is a “bubbling up” attack. That is the actual attack happens below the ISA (CPU) level in the computing stack.

Trying to stop such an attack is going to be difficult without hardware changes. For nearly all computer programs is the fundemental assumption that what you write to memory you read back from memory, the ability to break this assumption means that virtually all software can not be trusted any longer.

As Bruce has noted in the past, attacks do not get worse with time. Which is what we have seen with this attack. This trend will continue quite rapidly now because “there is blood in the water” and the sharks will come circling.

Thus the question to be asked is what level of fix is required at the hardware level. Much memory protection has relied on simple parity checking which only works for an odd number of bit changes in a memory word. Other techniques like mirroring might work but to what level? The reality of this is they are “bolt-ons” for detection and limited correction not real fixes.

The real solution is to identify the mechanism by which the attack class works and resolve this. There is a high probability that this will have a big impact on memory density thus making memory more expensive, and probably slower.

Not the sort of thing the industry will want to happen, as much of the profitable side of computing is now predicated on cheap memory in large quantities…

zelm • October 27, 2016 7:56 PM

Much memory protection has relied on simple parity checking which only works for an odd number of bit changes in a memory word.

ECC memory tends to use better codes, but I recall seeing references to parity in relation to CPU caches, which makes me wonder whether attacks like this could affect internal caches or registers.

Things like parity and ECC weren’t actually designed to guard against target bitflipping and it’d be risky to rely on them for that. An attack that works 0.1% of the time is probably still valuable given enough targets, and these researchers got much better than 0.1%.

The real solution is to identify the mechanism by which the attack class works and resolve this.

In theory cryptography could allow better error detection, too; though in practice, the number of bits needed to store a decent cryptographic hash is probably too large compared to cacheline sizes, at least for now.

Matthew • October 27, 2016 10:12 PM

Perhaps ALSR can help to mitigate this attack on the OS side. The attacks works only if you know which bits to flip.

I agree with Clive that a fix in memory hardware will expensive. We probably will not see much changes in consumer hardware but businesses will demand and pay for the hardware fixes to protect their virtual servers hosted on the cloud. Cloud providers will be worried a misbehaving VPS can mess up other VPS belong to other customers.

ATS • October 27, 2016 10:23 PM

@zelm

Things protected by parity tend to be pretty resilient. For instance, the L1D on Intel processors are protected by parity but also use highly resilient 8T SRAM cells.

Most ECC codes in use double as CRC codes. For main memory, esp for things like XEONs, the ECC is much more complex than simple classical hamming ECC codes.

Cryptographic hashes really don’t provide any more resiliancy than advanced ECC codes in use. For more enterprise systems, they aren’t doing ECC on 64b but on either 256b or 512b and so they generally have ~30b or ~60b for ECC coding using standard 72b dimms.

ECC actually goes quite a long ways to making rowhammer impracticable. And as far as memory protection, it is pretty much ECC or nothing and has been for a long time. Parity protected memory went away with x9 dram chips in the late 80s.

Hardware wise,there are already mechanisms specified in things like DDR4 to deal with targeted row attacks like demand based refresh.

Ross Anderson • October 28, 2016 5:35 AM

I was at the CCS talk, and was duly impressed. Here are my notes.

5pm session 8B: Drammer. The x86 hammer tricks don’t work on ARM so you use the DMA machinery to scan the memory for vulnerable bit flips; then land a page table there (the first 12 bits are the translation table base register, then 8 bits of second level table). But now we no longer have access to pagemap, how do we land a page table on a vulnerable memory cell? Phys Feng Shui (PPS) is basically a brute force search, followed by exhausting all memory except the target, so the kernel has no choice. A workable strategy is to exploit the predictability of Buddy Allocator, which can allocate stuff in 64kb chunks if you prep it by grabbing and releasing such chunks; then if you get a flippable sixth bit you can make it all line up, and overwrite struc_cred to get root privilege. The Nexus 5 had 0, 1k or 747k bit flips in three different handsets. Google asked them to delay or obfuscate, which the team refused; wouldn’t pay the $4000 bug bounty; and say there will be a fix of sorts in November. Using DMA bypasses defences like Anvil (which measures cache misses). https://vusec.net/projects/drammer

Tatütata • October 28, 2016 6:17 AM

This attack relies on the idea that when you hammer a memory region sufficiently hard an attacker has a fair notion of which other regions might be affected — namely, the neighbouring row.

Why should this be predictable? Neglecting the complexities of DRAM (row/column organisation, DDR, refreshing), must A0..Axx on the memory be mapped to A0..Axx on the CPU?

A (SO-)DIMM typically provides one chip per data bus bit. A permutation of the address lines between chips would suffice to ensure that when that hammering stunt is tried, bits would be clobbered all over the memory, and not simply in an identifiable adjacent row.

This could be achieved in the DIMM PCB design, with a laser modification of the mask on a per-module basis, or by providing a set of masks.

Even a static permutation might help.

If the chip are mounted directly in the end-device, such as in a smart phone, then the measure could be provided during chip manufacturing. A large number of permutations would be possible by providing a slightly different mask for every chip on a 30cm wafer, and shuffling the resulting devices like a deck of cards for good measure. Seen from its external ports, chips would remain functionally equivalent.

An address-bus mapping function could also be provided on the memory chip, if additional gate delays are allowable.

It seems that the task of an attacker would be complicated.

Is my idea too simplistic? What am overlooking here?

Clive Robinson • October 28, 2016 10:54 AM

@ Tatütata,

Is my idea too simplistic? What am overlooking here?

In the case of some memory chips not all addresses are equal in terms of access speed. That is in some memory types adjacent addresses in a column or row will be accessed faster than those in different rows or columns.

Further rearaging the addresses on the sub PCB is not that easy, thus there would only be limited permutations available. Whilst this would make device testing more complex it would not of necesity make it any harder for the attacker. Because they could just hammer enough memory to be able to tell which permutation was in use.

To make the idea work you need to not only remap the addresses but also change the memory word contents between the CPU and the actual storage cells.

Thus you are looking to encrypt the data bus and do something similar to the address bus, and swallow the extra logic delay that could reduce the memory access speed by 50% or more. You would also need to use a randonly generated key.

One problem you will almost immediately bump into is the varying size of the address bus in various versions. Whilst an encryption algorithm is guarenteed to have a one-one mapping across the full data width the same is very much not true if you only use part of the data width. It would also be likely that more than one or more data words would decode to more than one address. Thus any algorithm used would have to have certain charecteristics to prevent such an occurrence.

hawk • October 28, 2016 11:14 AM

@Clive Robinson

Re: “As Bruce has noted in the past, attacks do not get worse with time. ”

Do you mean the opposite?

Clive Robinson • October 28, 2016 11:33 AM

@ Hawk,

Do you mean the opposite?

Err do you mean,

better or stay the same

If so can I ask what your definition / perspective of “better” would be?

As far as I can tell attacks do not suffer from entropy or “bit rot” they either retain the same potency with time, or their potency is enhanced. What may cause an attack to nolonger work, is if the software supplier upgrades the software, either to eliminate the threat, or upgrade the software functionality that in the process stops the attack working.

Abbot Pascal • October 28, 2016 1:33 PM

@Tatu,

If you’re seeking out resistant hardware the original papers (not these ARM enhanced ones) stated that DDR3+ was vulnerable due to miniturization. While DDR2 could theoretically be vulnerable we have seen zero papers to indicate including the evidence here in this ARM enhanced variant which is implying that there’s a certain barrier that must be breached first. The S3 is looking better and better every day. More to the point, if you must use commodity consumer hardware grab something with DDR2 if you can’t get something cheap that supports ECC. I picked up 32cores of kernel building brawn w ECC for $250 bucks, supports qubes too.

Abbot Pascal • October 28, 2016 1:40 PM

The original Row Hammer papers also indicated that where DDR3 was concerned only specific manufacturing lines were affected by the bug. There may be a proprietary mitigation/design at play or available short of ECC. Does anyone know the actual companies affected by the original papers? and is it still too early to tell? 🙂

Who? • October 29, 2016 11:06 AM

The breakthrough has the potential to make millions of Android phones vulnerable, at least until a security fix is available

In other words, millions of Android devices (not only phones, also tablets) will remain vulnerable forever.

Clive Robinson • October 29, 2016 2:44 PM

@ Who?

In other words, millions of Android devices (not only phones, also tablets) will remain vulnerable forever.

Oh you forgot to mention the next three or four generations of hardware will in all likely hood be vulnerable as well (which is not just Android, but any current commercial OS).

But as for “forever”, theoretically yes, practically no.

The reason for this is many –if not most these days– have non user replacable batteries, and it’s not in a manufacturer’s interest to make the batteries available after they stop manufacturing them.

Further it is known that some manufactures have “chiped” their batteries –Apple and Asus have– and the units will not work with non OEM batteries, or do so very badly (it’s even rumored that like printer cartridges they might have expiry dates or limited recharge built in).

Sadly although these battery issues are in effect illegal –due to WEEE regulations– nobody appears to want to challenge it… Thus the resources such as rare earth metals etc are destined for landfill…

There will be one or two oddballs like myself who will “hackup” alternative power sources, so they can still be used as document readers etc, even that has a limited life. Document formats evolve continuously thus reader apps need to be upgraded. Frequently support for Android –or other OS– releases more than a couple of years old is the first thing that gets dropped by app developers.

I have one Android device that is about four years old and the hardware still works fine as does the hackup of the batteries I did. But PDF has newer features, and thus some newer PDF files can not be read, which sadly means the device even though it works and I could probably keep it going for several years has a premature EOL… I have similar issues with a Win2000 and WinXP box, as for NT, 95 and 3.11 I nolonger have to support them even though the tool chains I built still work fine, they will not run other peoples tools any longer so finally people are replacing their boxes.

However it’s worth keeping some going as I occasionaly get asked if I can copy stuff off of old 5 and 8 inch floppies and some older QIC type backup tapes and even zipdrives and a Bernoulli box that Iomega EOL’d thirty years ago… Oddly people are prepared to pay quite a bit for such a service…

A Nonny Bunny • October 29, 2016 2:55 PM

@Clive Robinson

If so can I ask what your definition / perspective of “better” would be?

It’s a question of point of view, I think. As attacks get better (for the attackers), they get worse (for the attacked); and vice versa.

Jimbo Bloggins • October 30, 2016 4:43 AM

The benefit of rooting phones is that you can put a terminal, a firewall and get r/w access to the system files, setup ssh, give it back to the owner and tell them “yeah it’s jailbroken dude”.

Schneier on Security

Hardware Bit-Flipping Attacks in Practice

Comments

Leave a comment Cancel reply