Initializing secure connection...
$ sudo systemctl start Steinz Security
$ loading security modules...
$ establishing encrypted tunnel...
$ authenticating user credentials...
$ access granted - welcome to the matrix

🎯 Rowhammer GPU Attack Can Remotely Hijack Android Mobiles

Steinz@security-lab:~$
root@security-lab:~#sudo ./exploit_analyzer.sh
Starting security analysis...
Vulnerability assessment complete ✓
root@security-lab:~#echo "Displaying full report..."
Security researchers have find out ways to hijack the Intel-compatible PCs running Linux by exploiting the physical weaknesses in certain varieties of DDR DRAM (double data rate dynamic random-access memory) chips and gaining higher kernel privileges on the system.

Google's Project Zero found Rowhammer in 2015, when they demonstrated that careful RAM bit-flipping in page table entries could let an attacker pwn Linux systems.




Since the bug upsets the operating system by attacking memory rather than looking for developers' errors, it's potent even if it's limited to types of memory that aren't protected by error checks (such as ECC in newer RAM).

Ever since Project Zero's initial result, boffins have looked for other vectors or other victims (for example, it was turned into an Android root attack in 2016).

Rowhammer is a problem with recent generation DRAM chips in which repeatedly accessing a row of memory can cause "bit flipping" in an adjacent row which could allow anyone to change the value of contents stored in computer memory.

WHAT IS ROWHAMMER BUG

DDR memory is arranged in an array of rows and columns, which are assigned to various services, applications and OS resources in large blocks. In order to prevent each application from accessing the memory of other application, they are kept in a "sandbox" protection layer.
However, Sandbox protection can be bypassed using Bit flipping technique in which a malicious application needs to repeatedly access adjacent rows of memory in a tiny fraction of a second.
As a result, hammering two aggressor memory regions can disturb neighbouring locations, causing charge to leak into or out of neighbouring cells.
“With enough accesses, this can change a cell’s value from 1 to 0 or vice versa. In other words, the selected zero area will be transferred to the victims, or vice versa.” researchers explained.

The Bit flipping technique was first presented in an experimental study paper published by Carnegie Mellon University, entitled, "Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors."
Bit flipping technique shouldn’t be confused with Buffer overflow or use-after-free memory corruption techniques where an attacker funnels malicious shellcode into protected regions of victim’s computer.

TWO WORKING EXPLOITS DEMONSTRATE THE FLAW

As we know, DRAM manufacturing scales down chip features to smaller physical dimensions. Latest Technology demands more memory capacity onto a chip, so it has become harder to prevent DRAM cells from interacting electrically with each other.
The Project Zero team has folded such bit flipping into an actual attack by demonstrating two proof-of-concept exploits that successfully take over control of many x86 computers running Linux and believes the same could be done with other operating systems as well.
First, Page table entries (PTEs) based exploit uses rowhammer induced bit flips to achieve kernel privileges on x86-64 Linux and hence, gain read-write access to entire of physical memory.
Second exploit demonstrates the exploitation of same vulnerability by escaping from the Native Client sandbox.

Two ingredients are required for this routine to cause bit flips:


Address selection:

For code1a to cause bit flips, addresses X and Y must map to different rows of DRAM in the same bank.

Each DRAM chip contains many rows of cells. Accessing a byte in memory involves transferring data from the row into the chip’s “row buffer” (discharging the row’s cells in the process), reading or writing the row buffer’s contents, and then copying the row buffer’s contents back to the original row’s cells (recharging the cells).

It is this process of “activating” a row (discharging and recharging it) that can disturb adjacent rows. If this is done enough times, in between automatic refreshes of the adjacent rows (which usually occur every 64ms), this can cause bit flips in the adjacent rows.

The row buffer acts as a cache, so if addresses X and Y point to the same row, then code1a will just read from the row buffer without activating the row repeatedly.

Furthermore, each bank of DRAM has its own notion of a “currently activated row”. So, if addresses X and Y point to different banks, code1a will just read from those banks’ row buffers without activating rows repeatedly. (Banks are groups of DRAM chips whose rows are activated in lockstep.)

However, if X and Y point to different rows in the same bank, code1a will cause X and Y’s rows to be repeatedly activated. This is termed “row hammering”.

Bypassing the cache:

Without code1a’s CLFLUSH instructions, the memory reads (MOVs) will be served from the CPU’s cache. Flushing the cache using CLFLUSH forces the memory accesses to be sent to the underlying DRAM, which is necessary to cause the rows to be repeatedly activated.

” The vulnerability eventually got assigned CVE-2018-10229.”

A Successful Privillage Escallation is shown in the below video




GLitch: New 'Rowhammer' Attack Can Remotely Hijack Android Phones


What is GLitch?

GLitch is one part of our series of Rowhammer attacks. We started by breaking the EDGE browser and the cloud. Then we moved towards Android devices showing how to root them with bit flips. This time we wanted to show that also mobile phones can be attacked remotely via the browser.

The first instance of a remote Rowhammer exploit on ARM Android devices. This makes it possible for an attacker who controls a malicious website to get remote code execution on a smartphone without relying on any software bug.

It is carried out by the GPU. This is the first GPU-accelerated Rowhammer attack.

GLitch is the first remote Rowhammer technique that exploits the graphics processing units (GPU), which is found in almost all mobile processors, instead of the CPU that was exploited in all previous theorized versions of the Rowhammer attack.

Since the ARM processors inside Android smartphones include a type of cache that makes it difficult to access targeted rows of memory, researchers make use of GPU, whose cache can be more easily controlled, allowing hackers to hammer targeted rows without any interference.

The technique is named GLitch with first two letters capitalized because it uses a widely used browser-based graphics code library known as WebGL for rendering graphics to trigger a known glitch in DDR3 and DDR4 memory chips.

Currently, GLitch targets smartphones running the Snapdragon 800 and 801 system on a chip—that includes both CPU and GPU—meaning the PoC works only on older Android phones like the LG Nexus 5, HTC One M8, or LG G2. The attack can be launched against Firefox and Chrome.

 How is it possible to trigger bit flips from the browser through the GPU?

The answer to this question is WebGL. WebGL is a graphic API that was designed with the purpose of providing developers with GPU acceleration for their graphics intensive applications. Unfortunately, as a byproduct of this API a new attack vector is introduced: the Grand Pwning Unit.

 

How Does This attack work?

GLitch exploits a series of microarchitectural flaws of the system in order to leak and corrupt data.  The attack can be divided in two stages:
  
  1)  In the first stage of the attack we take advantage of a timing side channel to gain a better understanding of the (physical) memory layout of the system.
   2)  In the second stage we use the information extracted from the previous part to carry out a more reliable Rowhammer attack against the browser – in our case Firefox. For more details about the exploitation go down.

But Why from GPU ?

he reason is that Rowhammer requires un-cached memory access. That is, it needs to bypass the processor caches to reach DRAM.  While natively the attacker has more power and he is allowed to directly bypass the caches, this doesn’t apply to JavaScript. From JS this can be achieved only by means of cache evictions. And this technique was proven unfeasible on Android (ARM) platforms.  Therefore, we needed a different attack vector. And here is where the GPU came into play. GPU caches were nicer and had deterministic behaviour making it easier for us to build low-noise side channels and remote Rowhammer attacks.

No Software Patch Can Fully Fix the Rowhammer Issue

Since Rowhammer exploits a computer hardware weakness, no software patch can completely fix the issue. Researchers say the Rowhammer threat is not only real but also has the potential to cause some real, severe damage.

Although there's no way to fully block an Android phone's GPU from tampering with the DRAM, the team has been working with Google on ways to solve the problem.

You can get the other details from the VUsec website and if you are interested in checking out the complete info about GLich you can get the PDF here

💬 Security Discussion

Comments are disabled for this post.