A Rowhammer ban-hammer for all, and it’s all in software (The Register)

A group of German researchers reckon they’ve cracked a pretty hard nut indeed: how to protect all x86 architectures from the “Rowhammer” memory bug.

It’s been 18 months since “Rowhammer” first emerged, and responses have largely come from individual vendors working out how to block the “bit-flipping” attacks in their own environments.

LWN reported last October that Linux kernel gurus are working on a generic defence that would work in their environment – but it would be even better if the whole x86 world could be protected.

That’s what the authors of this ArXiv paper claim: a software-only defence for x86 and ARM machines that isolates the memory of different system entities – for example, the kernel from the user space.

The researchers hail from Germany’s Technical University of Darmstadt and the University of Duisburg-Essen.

To understand the protection, a Rowhammer refresh is probably useful because if you can force corruption into DRAM, you can theoretically find a way to take over the kernel.

It was Google’s Project Zero that changed theory into proof-of-concept, and as The Register’s Iain Thomson reported at the time:

“The technique, dubbed ‘rowhammer’, rapidly writes and rewrites memory to force capacitor errors in DRAM, which can be exploited to gain control of the system. By repeatedly recharging one line of RAM cells, bits in an adjacent line can be altered, thus corrupting the data stored.

“This corruption can lead to the wrong instructions being executed, or control structures that govern how memory is assigned to programs being altered – the latter case can be used by a normal program to gain kernel-level privileges.”

With access to the physical RAM, the Project Zero attackers could then bypass memory protection and security mechanisms, and tamper with operating system structures to take over the machine.

As the new paper’s authors write, most protections against Rowhammer involved either modifying hardware, or ran heuristics-based counters against CPUs to raise alerts.

The Duisburg-Essen group has taken a different approach: their G-CATT (Generic CAn’t Touch This) is built on their x86-only B-CATT (Bootloader CAn’t Touch This), which extended the bootloader to disable vulnerable physical memory.

The bootloader approach, however, was Rowhammer-specific: “it does not yet tackle the fundamental problem of missing memory isolation in physical memory” – which is why the researchers extended their work to try and make it “generic”.

G-CATT takes a different angle: instead of isolating memory, it defeats Rowhammer by stopping an attacker from exploiting its effects, by ensuring attackers can only flip bits in memory already under their control.

That restriction “tolerates Rowhammer-induced bit flips, but prevents bit flips from affecting memory belonging to higher-privileged security domains” (such as the OS kernel, or co-located virtual machines); “to do so, G-CATT extends the physical memory allocator to partition the physical memory into security domains.”

Block diagrams of B-CATT and G-CATT

B-CATT and G-CATT block diagrams

It’s no good if the defence renders the system unusable, so the researchers also ran a bunch of benchmarks on their protected machines (using both B-CATT and G-CATT under Linux).

Under SPEC2006 (which test the performance on a bunch of different programs), the average B-CATT performance hit was 0.43 per cent and 0.49 per cent for G-CATT.

The Phoronix benchmark performance was better – B-CATT slowed things down by 0.19 per cent and G-CATT by 0.33 per cent.

The two systems ran well on file and VM latency tests, and the two protection schemes had minimal impact on local bandwidth and memory latency. ®

The state of mobile security maturity

Source: SANS ISC SecNewsFeed @ November 29, 2016 at 12:15AM