21 comments

[ 2.2 ms ] story [ 51.4 ms ] thread
Would you buy a hammer that can't ever hurt your thumb? What implications would that have? Would that be a good hammer?

Bad opinion time that I hope will maybe at least be thought provoking: I would hope a malicious app I willingly installed will be able to behave maliciously. Our security bureaucracy is going to grow exponentially and people are still going to be stealing people's shit, because people need to be able to access their shit and people are dumb.

> Requires a victim to first install a malicious app on an Android phone or tablet

As Raymond Chen/Old New Thing likes to say this rather requires being on the other side of this airtight hatchway. You can allow apps to do things on your device.

Raymond Chen's saying is about trust boundaries. That if there's no trust boundary defined, or if a defined boundary is being crossed with consent, then it is unsound to claim there being a security vulnerability (which would be a behavior that allows for crossing a trust boundary without consent).

This doesn't apply in this case, as (usermode apps') screen capturing does require permission, and applications can specifically opt-out from being captured by apps even with that permission, which Google Authenticator does have set. So a trust boundary is being violated, therefore this is a legitimate security issue by his logic.

And they can’t with iPhones?
(comment deleted)
You can't put one app on top of another, so that mitigates at least the 1st stage of this kind of attack.
Android supremacy at its finest. I would never recommend a family member buying one. The history of this kind of thing is long and keeps continuing to happen.
TL;DR; This is a timing attack on rendering that allows capture of screen data.
Don't worry you won't be able to install the bad application in the first place thanks to the new ID backed app signature.
This is a really interesting new side channel attack. One I had never considered before; it’s like rowhammer but for the screen. Clever. Also evil.

Clever and evil.

I'm stuck on the part of the attack where the malicious app opens another app:

> 2. Attacker app opens Google Authenticator's main activity

> 3. Attacker app opens a stack of activities to include graphical operations on pixels displayed by Google Authenticator's main activity

Android allows apps to call other apps? While remaining in the foreground? How does that work? I don't think iOS allows this.

More accurate title: "There's a new trojan out for android. Like any trojan, it gives the attacker access to things they shouldn't have access to"
It's a cool and interesting type of attack, but I really don't care for the breathless clickbait headlines that are sourced to a few security researchers demonstrating an attack in a lab, that has already been patched against and has never been seen in the wild.
In Android world, there is not such thing as "has been patched". It is always A complex situation with all different OEMs, devices and versions.

The patch was committed about 3 months ago, possibly available to OEMs as binary earlier, but devices are probably just receiving these patches.

I bet at least half of all affected Android devices in the world have not got the patch yet if I am optimistic. It's probably near 80-90%.

Could this be mitigated by introducing some random timing jitter during rendering?
Curious if the same technique would also work on Wayland, given one of its design goals is higher cross-app security compared to Xorg.
Just use the Google Authenticator's "Privacy Screen" which requires a PIN, pattern, or biometric verification to open the app. This renders this hack unusable ;-)
Tldr: this is a timing-based side channel in GPUs allowing and attacker to read pixels from the screen without special privs.

Side channels are why we can't have nice things.

tl;dr: This hack is "using a timing attack exploiting the GPU's graphical data compression to try finding out the color of the pixels."
> Does Google plan to patch these APIs? > > Google has attempted to patch Pixnapping by limiting the number of activities an app can invoke blur on. However, we discovered a workaround to make Pixnapping work despite this patch. The workaround is still under embargo.

Can I assume this is being exploited in the wild? Some black hats must be smart enough to figure out the workaround on their own.