Rowhammer

5 Articles

This Week In Security: M1RACLES, The Full Half-Double, And Patch Gaps

May 28, 2021 by 10 Comments

We occasionally make fun of new security vulnerabilities that have a catchy name and shiny website. We’re breaking new ground here, though, in covering a shiny website that makes fun of itself. So first off, this is a real vulnerability in Apple’s brand-new M1 chip. It’s got CVE-2021-30747, and in some very limited cases, it could be used for something malicious. The full name is M1ssing Register Access Controls Leak EL0 State, or M1RACLES. To translate that trying-too-hard-to-be-clever name to English, a CPU register is left open to read/write access from unprivileged userspace. It happens to be a two-bit register that doesn’t have a documented purpose, so it’s perfect for smuggling data between processes.

Do note that this is an undocumented register. If it turns out that it actually does something important, this vulnerability could get more serious in a hurry. Until then, thinking of it as a two-bit vulnerability seems accurate. For now, however, the most we have to worry about is that two processes can use this to pass information back and forth. This isn’t like Spectre or Rowhammer where one process is reading or writing to an unrelated process, but both of them have to be in on the game.

The discoverer, [Hector Martin], points out one example where this could actually be abused: to bypass permissions on iOS devices. It’s a clever scenario. Third party keyboards have always been just a little worrying, because they run code that can see everything you type, passwords included. The long-standing advice has been to never use such a keyboard, if it asks for network access permissions. Apple has made this advice into a platform rule — no iOS keyboards get network access. What if a device had a second malicious app installed, that did have Internet access permissions? With a covert data channel, the keyboard could shuffle keystrokes off to its sister app, and get your secrets off the device.

So how much should you care about CVE-2021-30747? Probably not much. The shiny site is really a social experiment to see how many of us would write up the vulnerability without being in on the joke. Why go to the hassle? Apparently it was all an excuse to make this video, featuring the appropriate Bad Apple!! music video.

Half-Double’ing Down on Rowhammer

A few days ago, Google announced the details of Half-Double, and the glass is definitely Half-Double full with all the silly puns that come to mind. The concept is simple: If Rowhammer works because individual rows of ram are so physically close together, does further miniaturization enable attacks against bits two rows away? The answer is a qualified yes.

Quick refresher, Rowhammer is an attack first demonstrated against DDR3 back in 2014, where rapid access to one row of memory can cause bit-flip errors in the neighboring row. Since then, there have been efforts by chip manufacturers to harden against Rowhammer, including detection techniques. At the same time, researchers have kept advancing the art through techniques like Double-Sided Rowhammer, randomizing the order of reads, and attempts to synchronize the attack with the ram’s refresh intervals. Half-Double is yet another way to overcome the protections built into modern ram chips.

We start by specifying a particular ram row as the victim (V). The row right beside it will be the near aggressor row (N), and the next row over we call the far aggressor row (F). A normal Rowhammer attack would simply alternate between reading from the near aggressor and a far-off decoy, rapidly toggling the row select line, which degrades the physical charge in neighboring bits. The Half-Double attack instead alternates between the far aggressor and a decoy row for 1000 cycles, and then reads from the near aggressor once. This process is repeated until the victim row has a bit flip, which often happens within a few dozen iterations. Because the hammering isn’t right beside the victim row, the built-in detection applies mitigations to the wrong row, allowing the attack to succeed in spite of the mitigations.

More Vulnerable Windows Servers

We talked about CVE-2021-31166 two weeks ago, a wormable flaw in Windows’ http.sys driver. [Jim DeVries] started wondering something as soon as he heard about the CVE. Was Windows Remote Management, running on port 5985, also vulnerable? Nobody seemed to know, so he took matters into hiis own hands, and confirmed that yes, WinRM is also vulnerable to this flaw. From what I can tell, this is installed and enabled by default on every modern Windows server.

And far from his optimistic assertion that surely no-one would expose that to the Internet… It’s estimated that there over 2 million IPs doing just that.

More Ransomware

On the ransomware front, there is an interesting story out of The Republic of Ireland. The health system there was hit by Conti ransomware, and the price for decryption set at the equivalent of $20 million. It came as a surprise, then, when a decryptor was freely published. There seems to be an ongoing theme in ransomware, that the larger groups are trying to manage how much attention they draw. On the other hand, this ransomware attack includes a threat to release private information, and the Conti group is still trying to extort money to prevent it. It’s an odd situation, to be sure.

Inside Baseball for Security News

I found a series of stories and tweets rather interesting, starting with the May Android updates at the beginning of the month. [Liam Tung] at ZDNet does a good job laying out the basics. First, when Google announced the May Android updates, they pointed out four vulnerabilities as possibly being actively exploited. Dan Goodin over at Ars Technica took umbrage with the imprecise language, calling the announcement “vague to the point of being meaningless”.

Shane Huntley jumped into the fray on Twitter, and hinted at the backstory behind the vague warning. There are two possibilities that really make sense here. The first is that exploits have been found for sale somewhere, like a hacker forum. It’s not always obvious if an exploit has indeed been sold to someone using it. The other possibility given is that when Google was notified about the active exploit, there was a requirement that certain details not be shared publicly. So next time you see a big organization like Google hedge their language in an obvious and seemingly unhelpful way, it’s possible that there’s some interesting situation driving that language. Time will tell.

The Patch Gap

The term has been around since at least 2005, but it seems like we’re hearing more and more about patch gap problems. The exact definition varies, depending on who is using the term, and what product they are selling. A good working definition is the time between a vulnerability being public knowledge and an update being available to fix the vulnerability.

There are more common reasons for patch gaps, like vulnerabilities getting dropped online without any coordinated disclosure. Another, more interesting cause is when an upstream problem gets fixed and publicly announced, and it takes time to get the fix pulled in. The example in question this week is Safari, and a fix in upstream WebKit. The bug in the new AudioWorklets feature is a type confusion that provides an easy way to do audio processing in a background thread. When initializing a new worker thread, the programmer can use their own constructor to build the thread object. The function that kicks off execution doesn’t actually check that it’s been given a proper object type, and the object gets cast to the right type. Code is executed as if it was correct, usually leading to a crash.

The bug was fixed upstream shortly after a Safari update was shipped. It’s thought that Apple ran with the understanding that this couldn’t be used for an actual RCE, and therefore hadn’t issued a security update to fix it. The problem there is that it is exploitable, and a PoC exploit has been available for a week. As is often the case, this vulnerability would need to be combined with at least one more exploit to overcome the security hardening and sandboxing built into modern browsers.

There’s one more quirk that makes this bug extra dangerous, though. On iOS devices, when you download a different browser, you’re essentially running Safari with a different skin pasted on top. As far as I know, there is no way to mitigate against this bug on an iOS device. Maybe be extra careful about what websites you visit for a few days, until this get fixed.

Via Ars Technica

Spoiler, Use-After-Free, And Ghidra: This Week In Computer Security

March 13, 2019 by 24 Comments

The past few days have been busy if you’re trying to keep up with the pace of computer security news. Between a serious Chromium bug that’s actively being exploited on Windows 7 systems, the NSA releasing one of their tools as an open source project, and a new Spectre-like speculative execution flaw in Intel processors, there’s a lot to digest.
Continue reading “Spoiler, Use-After-Free, And Ghidra: This Week In Computer Security” →

Peering Into A Running Brain: SDRAM Refresh Analyzed From Userspace

December 28, 2018 by 7 Comments

Over on the Cloudflare blog, [Marek] found himself wondering about computer memory, as we all sometimes do. Specifically, he pondered if he could detect the refresh of his SDRAM from within a running program. We’re probably not ruining the surprise by telling you that the answer is yes — with a little more than 100 lines of C and help from our old friend the Fast Fourier Transform (FFT), [Marek] was able to detect SDRAM refresh cycles every 7818.6 ns, lining right up with the expected result.

The “D” in SDRAM stands for dynamic, meaning that unless periodically refreshed by reading and writing, data in the memory will decay. In this kind of memory, each bit is stored as a charge on a tiny capacitor. Given enough time (which varies with ambient temperature), this charge can leak away to neighboring silicon, turning all the 1s to 0s, and destroying the data. To combat this process, the memory controller periodically issues a refresh command which reads the data before it decays, then writes the data back to fully charge the capacitors again. Done often enough, this will preserve the memory contents indefinitely. SDRAM is relatively inexpensive and available in large capacity compared to the alternatives, but the drawback is that the CPU can’t access the portion of memory being refreshed, so execution gets delayed a little whenever a memory access and refresh cycle collide.

Chasing the Correct Hiccup

[Marek] figured that he could detect this “hiccup,” as he calls it, by running some memory accesses and recording the current time in a tight loop. Of course, the cache on modern CPUs would mean that for a small amount of data, the SDRAM would never be accessed, so he flushes the cache each time. The source code, which is available on GitHub, outputs the time taken by each iteration of the inner loop. In his case, the loop typically takes around 140 ns.

Hurray! The first frequency spike is indeed what we were looking for, and indeed does correlate with the refresh times.

The other spikes at 256kHz, 384kHz, 512kHz and so on, are multiplies of our base frequency of 128kHz called harmonics. These are a side effect of performing FFT on something like a square wave and totally expected.

As [Marek] notes, the raw data doesn’t reveal too much. After all, there are a lot of things that can cause little delays in a modern multitasking operating system, resulting in very noisy data. Even thresholding and resampling the data doesn’t bring refresh hiccups to the fore. To detect the SDRAM refresh cycles, he turned to the FFT, an efficient algorithm for computing the discrete Fourier transform, which excels at revealing periodicity. A few lines of python produced the desired result: a plot of the frequency spectrum of the lengthened loop iterations. Zooming in, he found the first frequency spike at 127.9 kHz, corresponding to the SDRAMs refresh period of 7.81 us, along with a number of other spikes representing harmonics of this fundamental frequency. To facilitate others’ experiments, [Marek] has created a command line version of the tool you can run on your own machine.

If this technique seems familiar, it may be because it’s similar the the Rowhammer attack we covered back in 2015, which can actually change data in SDRAM on vulnerable machines by rapidly accessing adjacent rows. As [Marek] points out, the fact that you can make these kinds of measurements from a userspace program can have profound security implications, as we saw with the meltdown and spectre attacks. We have to wonder what other vulnerabilities are lying inside our machines waiting to be discovered.

Thanks to [anfractuosity] for the tip!

33C3: Memory Deduplication, The Hacker’s Friend

February 4, 2017 by 11 Comments

At the 33rd annual Chaos Communications Congress, [Antonio Barresi] and [Erik Bosman] presented not one, not two, but three (3!!) great hacks that were all based on exploiting memory de-duplication in virtual machines. If you’re interested in security, you should definitely watch the talk, embedded below. And grab the slides too. (PDF)

Memory de-duplication is the forbidden fruit for large VM setups — obviously dangerous but so tempting. Imagine that you’re hosting VMs and you notice that many of the machines have the same things in memory at the same time. Maybe we’re all watching the same cat videos. They can save on global memory across the machines by simply storing one copy of the cat video and pointing to the shared memory block from each of the machines that uses it. Notionally separate machines are sharing memory. What could go wrong?

Continue reading “33C3: Memory Deduplication, The Hacker’s Friend” →

Creative DRAM Abuse With Rowhammer

March 13, 2015 by 70 Comments

Project Zero, Google’s security analyst unit, has proved that rowhammer can be used as an exploit to gain superuser privileges on some computers. Row Hammer, or rowhammer is a method of flipping bits in DRAM by hammering rows with fast read accesses. [Mark Seaborn] and the rest of the Project Zero team learned of rowhammer by reading [Yoongu Kim’s] 2014 paper “Flipping Bits in Memory Without Accessing Them:
An Experimental Study of DRAM Disturbance Errors” (PDF link). According to [Kim], the memory industry has known about the issue since at least 2012, when Intel began filing patents for mitigation techniques.

“Row hammer” by Dsimic – Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons.

The technique is deceptively simple. Dynamic RAM is organized into a matrix of rows and columns. By performing fast reads on addresses in the same row, bits in adjacent rows can be flipped. In the example image to the left, fast reads on the purple row can cause bit flips in either of the yellow rows. The Project Zero team discovered an even more aggressive technique they call “double-sided hammering”. In this case, fast reads are performed on both yellow rows. The team found that double-sided hammering can cause more than 25 bits to flip in a single row on a particularly vulnerable computer.

Why does this happen? The answer lies within the internal structure of DRAM, and a bit of semiconductor physics. A DRAM memory bit is essentially a transistor and a capacitor. Data is stored by charging up the capacitor, which immediately begins to leak. DRAM must be refreshed before all the charge leaks away. Typically this refresh happens every 64ms. Higher density RAM chips have forced these capacitors to be closer together than ever before. So close in fact, that they can interact. Repeated reads of one row will cause the capacitors in adjacent rows to leak charge faster than normal. If enough charge leaks away before a refresh, the bit stored by that capacitor will flip.

Cache is not the answer

If you’re thinking that memory subsystems shouldn’t work this way due to cache, you’re right. Under normal circumstances, repeated data reads would be stored in the processor’s data cache and never touch RAM. Cache can be flushed though, which is exactly what the Project Zero team is doing. The X86 CLFLUSH opcode ensures that each read will go out to physical RAM.

Wanton bit flipping is all fine and good, but the Project Zero team’s goal was to use the technique as an exploit. To pull that off, they had to figure out which bits they were flipping, and flip them in such a way as to give elevated access to a user level process. The Project Zero team eventually came up with two working exploits. One works to escape Google’s Native Client (NaCL) sandbox. The other exploit works as a userspace program on x86-64 Linux boxes.

Native Client sandbox escape exploit

Google defines Native Client (NaCL) as ” a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.”  It was designed specifically as a way to run code in the browser, without the risk of it escaping to the host system.  Let that sink in for a moment. Now consider the fact that rowhammer is able to escape the walled garden and access physical memory. The exploit works by allocating 250MB of memory, and rowhammering on random addresses, and checking for bit flips. Once bit flips are detected, the real fun starts. The exploit hides unsafe instructions inside immediate arguments of “safe” institutions. In an example from the paper:

20EA0: 48 b8 0f 05 EB 0C F4 F4 F4 F4 movabs $0xF4F4F4F40CEB050F,%rax 

Viewed from memory address 0x20EA0, this is an absolute move of a 64 bit value to register rax. However, if we move off alignment and read the instruction from address 0x20EA02, now it’s a SYSCALL – (0F 05).  The NaCL escape exploit does exactly this, running shell commands which were hidden inside instructions that appeared to be safe.

Linux kernel privilege escalation exploit

The Project Zero team used rowhammer to give a Linux process access to all of physical memory. The process is more complex than the NaCL exploit, but the basic idea revolves around page table entries (PTE). Since the underlying structure of Linux’s page table is well known, rowhammer can be used to modify the bits which are used to translate virtual to physical addresses. By carefully controlling which bits are flipped, the attacking process can relocate its own pages anywhere in RAM. The team used this technique to redirect /bin/ping to their own shell code. Since Ping normally runs with superuser privileges, the shell code can do anything it wants.

The TL;DR

Rowhammer is a nasty vulnerability, but the sky isn’t falling just yet. Google has already patched NaCL by removing access to the CLFLUSH opcode, so NaCL is safe from any currently known rowhammer attacks. Project Zero didn’t run an exhaustive test to find out which computer and RAM manufacturers are vulnerable to rowhammer. In fact, they were only able to flip bits on laptops. The desktop machines they tried used ECC RAM, which may have corrected the bit flips as they happened. ECC RAM will help, but doesn’t guarantee protection from rowhammer – especially when multiple bit flips occur. The best protection is a new machine – New RAM technologies include mitigation techniques. The LPDDR4 standard includes “Targeted Row Refresh” (TRR) and “Maximum Activate Count” (MAC), both methods to avoid rowhammer vulnerability. That’s a good excuse to buy a new laptop if we ever heard one!

If you want to play along at home, the Project Zero team have a rowhammer test up on GitHub.