Hacker News Reader

Comment by rcthompson | Hacker News Reader

Is there any way to statically analyze an app for code that might be attempting to execute a rowhammer attack? I'd imagine that rowhammer requires a tight loop doing nothing but writing to the same value in memory repeatedly, or something similarly recognizable. Such a tool could be used to at least keep any malicious apps out of the play store. It would probably be fine if it sometimes gave false positives on innocuous code that a human (at Google) could override after inspecting the suspect code.

View on HN

Doubtful. A malicious app could always programatically write the attacking binary after it has been installed. At that point, you no longer have serious performance requirements, so you can make the functionality as obfuscated as necessary. Not to mention the possibility of self modifying code, or downloading the payload from the internet.

How much of this is possible within an Android app? Are Android apps allowed to download a file and then make it executable?

With root? Yes, you don't even need special permissions past an Internet permission.

SuperSU is popular app used to limit which apps can get root permission via the su binary. But depending on the way the device is rooted you can actually use root permission to remove SuperSU while leaving the binary that grants root in-tact.

This allows you to create a "backdoor" in which your "legitimate app" asks for root, then downloads an update and deletes SuperSU, allowing the payload (and any other apps) to get root access silently.

If you already have root, then you don't need to execute a rowhammer attack to gain root. I'm asking if an Android app with no root access on an un-rooted phone has a way to execute code that wasn't included with the apk, in order to hide the code that executes the rowhammer attack. If not, then a static analyzer that detects rowhammer attacks in the code of an apk would be sufficient.

Yes, it can.

Even then it's impossible to be certain, see https://en.wikipedia.org/wiki/Rice%27s_theorem - you cannot prove that a programme will or won't do a certain thing. It's not very intuitive, and the whole thing comes down to a clever reduction to the halting problem. The same reasoning also excludes the existence of a perfect virus scanner (even if you were to define a virus to be a programme that may open a dialog saying "VIRUS").

That doesn't mean that you can't catch most of the cases where a programme would do something like this. As they say, perfect is the enemy of good—in this case perfect is provably impossible, but that doesn't mean we shouldn't strive to find something that improves the current state. Google automatically scans all Play Store submissions for known malicious behaviour, they might be able to detect rowhammer exploits the same way.

>The same reasoning also excludes the existence of a perfect virus scanner (even if you were to define a virus to be a programme that may open a dialog saying "VIRUS").

It's a cute theorem, but it's more misleading than it is useful. Let's say we use a simple bytecode format for your programs. They can only open that dialog by having a call to the open-dialog function with a fixed parameter saying "VIRUS". We may not be able to say if an arbitrary program will run that call, but we can state with certainty whether it has that call. Such a program is either a virus or a virus decoy, and either way should be blocked.

We don't need to answer the question "Are we certain the program does X at runtime?". If we can answer "Does the program have an X-performing module?" that's good enough.

On android we can't answer that because the execution model is too powerful. But it's possible to make a practical app platform with the ability to answer that question.

The problem is that your execution model has to become incredibly constrained (no execve, no mmap, no function pointers and no reflection) in order to make that virus scanner work. I don't think that a general purpose programming language will be that useful if you disable all of those features.

You can even execute the rowhammer attack from the loaded javascript: https://github.com/IAIK/rowhammerjs There's no protection against it really. It doesn't matter if you can scan APKs for this behaviour if any app can open a webview with the right page.

Thanks, this pretty clearly answers the question.

mprotect(..., PROT_EXEC) works just fine on Android

I don't know why I got down voted for misunderstanding the question, the other way of understanding the question made it clearly sound impossible.

How was I supposed to understand that someone was really asking if there's a way for an Android app to change its behavior at runtime when all mobile platforms have access to JavaScript...

Sorry for the confusion. I wasn't aware that a rowhammer attack could be carried out even in a high-level language like JS.

Android isn't like iOS, so yes. An app can load in additional code into its processes after the fact.

Here's a dynamic approach to stopping rowhammer: http://www.openwall.com/lists/kernel-hardening/2016/10/27/18

>a human (at Google) could override

you cant be serious, google is not paying 200K for developers to play with individual cases of consumer/dev support. You cant even get Human support from google when you make >$100K a month in adsense/YT.

I think dynamic analysis would be more useful.

Reply on news.ycombinator.com