How Android Devices are Currently Vulnerable Because of Choice of Memory

Steve Smith talks about the RAMpage flaw in Android devices, how it works, the consequences, proof of concept codes, possible hardware solutions, risk mitigation and reality.

Episode #8-46 released on July 8, 2018

Watch on Youtube

Software and hardware are plagued with design flaws, and it is not if, but when, the next bug will be found in our software and hardware designs. The RAMpage flaw is yet another addition to the Rowhammer attack method.

Now, how does the RAMpage flaw work?

RAMpage works by having software writing repeatedly to specific sectors of accessible memory to that application, in an attempt to change the information in sectors nearby through the use of electrical fields.

What kinds of devices does this flaw affect?

RAMpage has been currently found to affect Android devices using the ION subsystem, which was released on October 18, 2011, as part of Android 4.0, meaning any device with Android 4.0 or higher and that have LPDDR2, LPDDR3, and LPDDR4 memory is currently affected by RAMpage. Meaning that Android devices released as far as 2012 are potentially affected. Now, researchers did release GuardION, a tool to mitigate the risks of RAMpage on Android, and this speaks to an issue that needs a software solution to deal with a hardware issue.

What are the consequences of the RAMpage flaw?

Data isolation becomes fundamentally broken, and data such as usernames, passwords, personal photos, emails, instant messages, documents, etc. can be accessed by carefully crafted applications designed to leverage the RAMpage flaw. It would do this by using the exploitable vector to attempt to gain administrative access to all the data that it could access.

Is there any known proof of concept code in the wild?

It is important to note, that currently there are no known PoC code or programs currently in circulation, or otherwise. However, when it does occur, and it will most likely occur, we will continue talking about it.

Would there be a way at the hardware level to fix this issue?

Yes, but the question is how? Using code to change the values of data in one section of memory to change data in another close section via electrical fields implies we'd need to explore using more insolation between the data nodes, but that would adversely affect the size of devices if not done with carefully. It is, also, important to note, that we are already approaching the limits in die shrink, anyway, so we may see a shift from silicon to other materials or methods for smaller and faster processors, memory, and devices. Hopefully, those methods will be free of many of the issues we currently experience with silicon chips with the size of dies we are working with.

Host : Steve Smith | Music : | Editor : Steve Smith | Producer : Zed Axis Dot Net

Sources & Resources

Community Comments

Share your thoughts, opinions and suggestions

Login or Register to post Your comment.