Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Network Security

// // //
5/18/2018
08:15 AM
Larry Loeb
Larry Loeb
Larry Loeb

Throwhammer & Nethhammer Show How Chips Are Vulnerable to Bit Flips

In a pair of papers released over the last week, researchers have shown how two different types of attacks, Throwhammer and Nethhammer, can cause a bit flip in chips by sending packets across a standard network.

First there was the Rowhammer problem. Researchers at Google identified a way that the RAM of a computer could be altered in its state -- bit flips -- to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process.

The bit flips, according to Google, that it caused in page table entries (PTEs) could allow malware to gain write access to its own page table, and hence gain read-write access to all of physical memory.

Running code on the victim machine was necessary to do this, which meant having the attack code placed on the machine itself or luring users to some website that hosted malicious JavaScript.

However, in the last two weeks, researchers at the Vrije Universiteit Amsterdam and the University of Cyprus showed how packets delivered to the victim machine over a network could cause the same type of vulnerability.

(Source: Pexels)
(Source: Pexels)

The network attack was enabled by fast network speeds that allowed the attacker to send specially designed packets in a rapid succession.

"We show that even at relatively modest network speeds of 10Gbps, it is possible to flip bits in a victim machine from across the network," according to the research paper.

The researcher's attack -- named Throwhammer -- was effective on servers using memcached techniques. This is a distributed memory caching system used by many websites to reduce pulling data from other external servers. In this method, an application will reserve space inside a network card to store packets it wants to store from remote direct memory access (RDMA) channels.

Throwhammer meant that cloud services were directly at risk to this attack from their networks if they used RAM chips that did not physically guard against bit flips such as DDR2, DDR3 or DDR4 chips.

Over this past weekend, however, separate research from the team that discovered the Spectre and Meltdown side-channel vulnerabilities in x86 chips showed that a network could deliver other ways to cause Rowhammer-style bit flips.

These researchers found that systems using uncached memory or flush instructions while handling network requests -- not just RDMA -- were vulnerable to what they called Nethammer.

The authors describe the situation: "Nethammer sends a crafted stream of network packets to the target device to mount a one-location or single-sided Rowhammer attack by exploiting quality-of-service technologies deployed on the device."

This means they found a way to bypass the caching that is routinely used and send the attack directly into the DRAM to cause the row conflicts required for hammering.

The attack requires high-speed connections.

"In our experiments, we sent a stream of UDP packets with up to 500 Mbps to the target system. We were able to induce a bit flip every 350 ms," according to the research note.

That need for speed may be a way to mitigate attacks of this kind. Controlling traffic spikes may be a way out, but even short spikes may allow this kind of attack.

Security has long focused on software as the attack enabler. Nethammer shows how hardware itself can be the underlying problem and how resistant it may be to a simple solution.

Related posts:

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Improving Enterprise Cybersecurity With XDR
Enterprises are looking at eXtended Detection and Response technologies to improve their abilities to detect, and respond to, threats. While endpoint detection and response is not new to enterprise security, organizations have to improve network visibility, expand data collection and expand threat hunting capabilites if they want their XDR deployments to succeed. This issue of Tech Insights also includes: a market overview for XDR from Omdia, questions to ask before deploying XDR, and an XDR primer.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2022-34835
PUBLISHED: 2022-06-30
In Das U-Boot through 2022.07-rc5, an integer signedness error and resultant stack-based buffer overflow in the "i2c md" command enables the corruption of the return address pointer of the do_i2c_md function.
CVE-2021-40597
PUBLISHED: 2022-06-29
The firmware of EDIMAX IC-3140W Version 3.11 is hardcoded with Administrator username and password.
CVE-2022-30467
PUBLISHED: 2022-06-29
Joy ebike Wolf Manufacturing year 2022 is vulnerable to Denial of service, which allows remote attackers to jam the key fob request via RF.
CVE-2022-33061
PUBLISHED: 2022-06-29
Online Railway Reservation System v1.0 was discovered to contain a SQL injection vulnerability via the id parameter at /classes/Master.php?f=delete_service.
CVE-2022-2073
PUBLISHED: 2022-06-29
Code Injection in GitHub repository getgrav/grav prior to 1.7.34.