Software Can’t Fully Fix This Massive New Security Flaw
Credit to Author: Andy Greenberg| Date: Wed, 15 Feb 2017 00:30:24 +0000
For the last decade or so, hackers have faced a daunting challenge when they try to break into a computer: Even when they get malicious code running on a victim’s machine, they have to figure out where in the computer’s memory that code has ended up. That’s because a security protection used in Windows, Android, and every other modern operating system randomizes where programs run in a device’s memory. It turns the process of digital intrusion into something like an attempt to burglarize a house in total darkness.
But now a team of Dutch researchers has found a technique that undermines that so-called address space layout randomization, creating the You Are Here arrow that hackers need to orient themselves inside a stranger’s computer. That means any of the common memory corruption bugs found in software applications on a daily basis could lead to a much deeper takeover of a target PC or smartphone. And because the attack exploits not software but hardware, it leaves millions of devices at risk regardless of their operating system—and it can’t be fully fixed with any mere software update.
Back in the ASLR
“Bugs are everywhere, but ASLR is a mitigation that makes bugs hard to exploit,” says Ben Gras, a researcher at the Free University of Amsterdam who developed the attack along with his colleague Kaveh Razavi. “This technique makes bugs that weren’t exploitable exploitable again. In some sense, it takes us back to the ’90s in terms of security.”
Their attack is particularly serious because attackers can pull it off with javascript alone, meaning that simply visiting a malicious website can trigger it; the research team, known as VUSec, released a demonstration video showing it running in a Firefox browser. “Nobody has done this before from the context of a web page,” says Yossi Oren, a researcher at Ben Gurion University who specializes in microarchitecture security. “It’s a very insidious and clever example of this class of attack.”
It may also be as difficult to fix as it is easy to deploy. The VUSec technique exploits the deepest properties of the computer’s hardware, the microprocessors made by companies including Intel, AMD, Nvidia, and Samsung. Making ASLR fully effective again, the researchers say, could require not just a quick operating system or browser update but also redesigning and replacing those chips.
Cracking the Safe
The attack exploits the way microprocessors and memory interact: Processors have a component called a memory management unit that maps where a computer stores programs in its memory. To keep track of those addresses, the MMU constantly checks a directory called a page table.
The key to the VUSec hack is that devices usually store the page table in the processor’s cache—a small chunk of memory that keeps frequently accessed information close to its computing cores. That makes the chip speedier and more efficient.
But a piece of malicious javascript code running on a website can write to that cache too. And, crucially, it can simultaneously watch how quickly the MMU is working. “By monitoring the MMU very closely, the javascript can find out about its own addresses, which it’s not supposed to do,” Gras says.
The VUSec researchers’ attack turns the MMU’s speed into a revealing clue. The attacking code overwrites the cache, one unit of memory at a time, until it sees the MMU slowing down. That’s a sign that whatever part of the cache got overwritten was a chunk of the page table the MMU was looking for—the MMU slows down because it has to go back to a copy of the page table in normal random-access memory instead of in the processor’s cache.
The MMU has to perform four separate page table checks to find the physical address of any given piece of code. So the attack overwrites the cache four times, ferreting out four places in the cache that have a piece of the page table. Each time, the malicious program notes the moment of the MMU’s slowdown. Just how long the MMU takes to hit that slowdown provides a hint as to the malicious code’s own address in the cache and therefore its location in RAM, when the device copies the hack from the cache to that other memory—the exact information that ASLR tries to hide from a hacker.
Think of the attack as an old-fashioned safecracker, listening with a stethoscope for telltale clicks while slowly turning a safe’s dial. “The cache is like the cogs in the safe that produce those little clicks that allow you to crack it,” Gras says.
A Deep Bug to Fix
Gras says VUSec reached out to the Netherlands’ National Cybersecurity Center, which contacted all the affected chipmakers and software companies—including Intel, AMD, Samsung, Nvidia, Microsoft, Apple, Google, and Mozilla—more than three months ago, but the researchers are only now going public with their findings after giving the companies a standard window to address them. The researchers aren’t releasing any code to demonstrate the attack. But they warn that skilled hackers could reverse-engineer the technique from what they’ve revealed in a matter of weeks.
Meanwhile, Gras suggests some band-aids. You can enable plug-ins, like NoScript for Firefox or ScriptSafe for Chrome, to block javascript on web pages. And browser-makers could conceivably reduce the exactness of the timing measurements they allow scripts to make, preventing them from monitoring the MMU’s speed.
At least one company has already worked to mitigate the dangers; Apple published a software update designed to “harden” Safari but didn’t reveal exactly what that update does. An Apple spokesperson says the company also distributed a plan of action to other affected vendors—likely the companies that build the chips it uses.
A full fix will ultimately require replacing hardware, not software. Devices will need new chips with new architectures that separate the MMU and its page table from the processor’s cache. “Because it’s at such a fundamental layer, the layers of software above can make it harder to exploit, but they can’t make it go away,” Gras says.
Intel, Microsoft, and Mozilla, meanwhile, downplayed the issue. “We’ve determined it does not represent a security issue,” says a statement Microsoft PR emailed to WIRED. Intel writes that the research “doesn’t represent a significant change in the security of Intel Architecture–based systems.” Spokespeople from all three companies point out that the attack alone only represents a threat in combination with another memory corruption bug. Samsung, Nvidia, AMD, and Google didn’t respond to WIRED’s request for comment.
It’s little comfort, however, for Microsoft and Intel to point out that defeating ASLR alone doesn’t allow someone to hack an operating system, Oren says. With ASLR broken, hackers will go back to hunting the kind of commonplace memory corruption bugs that ASLR rendered useless. Old bugs could learn new tricks.
The result, if tech firms don’t take the ASLR attack seriously, could soon be a bounty of new ways to hack millions of innocent users unlucky enough to click on the wrong web page. “Attackers are always getting smarter,” Oren says. “If computers are getting dumber, attackers will have the advantage.”