RowHammer strikes again

Before we get to the main event (just be patient), I want you to first spend a little time with something that I think is actually a much MORE interesting story about computer security: The strange story of “Extended Random”

Yesterday, David Benjamin posted a pretty esoteric note on the IETF’s TLS mailing list. At a superficial level, the post describes some seizure-inducingly boring flaws in older Canon printers. To most people that was a complete snooze. To me and some of my colleagues, however, it was like that scene in X-Files where Mulder and Scully finally learn that aliens are real.

Why is this such a great story?

1. Well, for one thing, it's been going on for more than a decade. That's a long time.
2. For another thing, the technology involved is quite complex: multiple software systems have to interact, in quite complex ways
3. And for another thing, at least one part of the overall vulnerability involves simply including additional COMPLETELY RANDOM DATA in your messages over the network. How is adding some extra random data a vulnerability? (You'll have to read the article for yourself)
4. But most importantly, as opposed to most computer security vulnerabilities, this isn't simply an implementation mistake made by some systems programmer; from everything we can determine, it is actually the result of deliberate sabotage by our own government, sabotage so subtle that, fifteen years later, the best cryptographic minds in the world are still picking through the details.

Anyway, enough of that.

I know what you came here for.

You want to hear what good old RowHammer has been up to over the last couple years, right?!

Well, unless you've been living in a cave (and who reads blogs if they live in a cave?), you know that what we're talking about here is Reading privileged memory with a side-channel, also known as: "the latest amazing work by the astonishing Google Project Zero team."

Well, anyway, here are the goods:

• Reading privileged memory with a side-channel

  We have discovered that CPU data cache timing can be abused to efficiently leak information out of mis-speculated execution, leading to (at worst) arbitrary virtual memory read vulnerabilities across local security boundaries in various contexts.

• Meltdown and Spectre

  These hardware bugs allow programs to steal data which is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.

• Meltdown

  Meltdown allows an adversary who can run code on the vulnerable processor to obtain a dump of the entire kernel address space, including any mapped physical memory. The root cause of the simplicity and strength of Meltdown are side effects caused by out-of-order execution.

• Spectre Attacks: Exploiting Speculative Execution

  in order to mount a Spectre attack, an attacker starts by locating a sequence of instructions within the process address space which when executed acts as a covert channel transmitter which leaks the victim’s memory or register contents. The attacker then tricks the CPU into speculatively and erroneously executing this instruction sequence, thereby leaking the victim’s information over the covert channel. Finally, the attacker retrieves the victim’s information over the covert channel. While the changes to the nominal CPU state resulting from this erroneous speculative execution are eventually reverted, changes to other microarchitectural parts of the CPU (such as cache contents) can survive nominal state reversion.

• Mitigations landing for new class of timing attack

  Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox. This includes both explicit sources, like performance.now(), and implicit sources that allow building high-resolution timers, viz., SharedArrayBuffer.

• KASLR is Dead: Long Live KASLR

  In this paper, we present KAISER, a highly-efficient practical system for kernel address isolation, implemented on top of a regular Ubuntu Linux. KAISER uses a shadow address space paging structure to separate kernel space and user space. The lower half of the shadow address space is synchronized between both paging structures.

• The mysterious case of the Linux Page Table Isolation patches

  Of particular interest with this patch set is that it touches a core, wholly fundamental pillar of the kernel (and its interface to userspace), and that it is obviously being rushed through with the greatest priority. When reading about memory management changes in Linux, usually the first reference to a change happens long before the change is ever merged, and usually after numerous rounds of review, rejection and flame war spanning many seasons and moon phases.

  The KAISER (now KPTI) series was merged in some time less than 3 months.

• Quiet in the peanut gallery

  I wish there were some moral to finish with, but really the holidays are over, the mystery continues, and all that remains is a bad taste from all the flack I have received for daring intrude upon the sacred WordPress-powered tapestry of a global security embargo.

• Re: Avoid speculative indirect calls in kernel

  I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.

  .. and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.

  Or is Intel basically saying "we are committed to selling you shit forever and ever, and never fixing anything"?

• Today's CPU vulnerability: what you need to know

  The Project Zero researcher, Jann Horn, demonstrated that malicious actors could take advantage of speculative execution to read system memory that should have been inaccessible.

It's pretty interesting stuff.

It will take a while to dig through and think about.

But, it's important to note: this is primarily an attack against large, shared servers, which typically run software on behalf of many unrelated parties on the same physical system, using techniques such as "virtualization", or "containers".

Think "cloud computing."

Those environments are the ones which are spending the most amount of time thinking about what these new findings mean.