Submitted 3 weeks ago by vegeta@lemmy.world to technology@lemmy.world
"Our end-to-end attacks simply measure the rendering time per frame of the graphical operations… to determine whether the pixel was white or non-white.”
This is a prime example of something that is so simple, yet elegant, and brilliant. Fantastically cool and scary.
Reminds me how in the early days the secret keys inside the smartchips in things like bank cards could be extracted by measuring the power consumption were the smartchips were doing things like signing data using those keys.
Would color text on color background foil this? Red text on a green background, etc
Not sure. Google patched it by just limiting the amount of blurs an app could request: …googlesource.com/…/20465375a1d0cb71cdb891235a9f8…
The new attack, named Pixnapping by the team of academic researchers who devised it, requires a victim to first install a malicious app on an Android phone or tablet. The app, which requires no system permissions, can then effectively read data that any other installed app displays on the screen. Pixnapping has been demonstrated on Google Pixel phones and the Samsung Galaxy S25 phone and likely could be modified to work on other models with additional work. Google released mitigations last month, but the researchers said a modified version of the attack works even when the update is installed.
Never ending side channel attacks. Stallman was right, only 100% FOSS gives you control over your device.
And given that a lot of this stuff is relying on timing the only reliable cure is to make everything slow. But no one wants that. Or maybe getting rid of precise timers in userspace. It would be funny if stopwatch precision was bound to screen refresh rate.
That wouldn’t be too bad. There could be a new permission for precise time.
You can implement a counting-thread that’s even more precise than the CPU’s timer (TSC on x86) platforms. This was shown in attacks on Intel SGX, where the rdtsc instruction to access the time-stamped counter is unavailable.
…and there you go:
ccs25files.zoolab.org/main/…/3719027.3765061.pdf
Literally published less than a day ago:
ExfilState: Automated Discovery of Timer-Free Cache Side Channels on ARM CPUs
This is a very big hypothetical.
They’d need to already have access to your account credentials (email, password or at least something that is regarded the same) then have you install this malicious app, then you’d need this app to be open at the same time as your 2FA app
It’s possible, yes, it’s an awesome find, yes, and this should be patches, yes yes yes, a thousand yes
Having said that, I’m not too worried about the potential impact of this, it’ll be fine.
Duh, they’re hackers /s
Dont install random shit and og possible have a phone just for 2fa
It doesn’t require any permissions. It could literally be in any app or even a demo
Yes that’s why you verify the safety and security of tge apps you’re installing on your phone and don’t just go, “ooo, this looks cool, let’s download it and try it out”. This is especially true if you are installing FOSS apps.
Even if this particular attack is against Android phones, it should be noted that iPhones have their own security issues.
Stay safe out there, regardless of what type of phone you use.
Lawl “exploit developed for android phones”
You: UK AKSHULLY IPHONES AREN’T SECURE THOUGH
Alternately: I was mentioning this to pre-empt anyone marching in here and puffing up about iPhone.
Of course you know and understand the intent of my comment. Your bad-faith response fails to impress.
Permissions, when built-in to the operating system from conception, are much more effective than when they’re half-heartedly tacked on decades later, which is why these issues keep coming up on Android but not on iOS
The difference isn’t actually in the operating system. iOS is just as vulnerable to such things. The difference is in how the app store is run. Apple locks down there app store so that it’s much more difficult to get malicious apps added. Google is extremely less thorough. Which is one of the reason many of us choose Android. When you choose more freedom the price is more vigilance is necessary to secure yourself and your phone.
Yes, this is why Androids and iPhone have different security issues.
As someone already pointed out it’s a lost game regardless of platform as long as closed source software is used on any machine anywhere it’s fundamentally unsafe. Black market operators like Israel’s Pegasus have been selling ios day 0 exploits for years and there are probably hundreds that exist out there.
The good part is that these rare exploits will not be used on you because they are too valuable the bad part is that the only way against them is full system transparency which is not happening anytime soon.
You hate iPhones so much that you have to take a security issue on Android and defend it by shouting “Apple too!”?
So you’re denying that iPhone have security issues?
Gotta wonder why random apps don’t need permissions to run and operate other apps. You can cause plenty of trouble maliciously navigating a browser even if you can’t see the screen.
Sandboxing by default and preventing Google and others from spying in and manipulating apps are good steps phone OS developers should use, but I don’t think those kind of things would help for this particular case.
Use open source apps and everything to be protected. Gotcha
It has to be tailored to the specific hardware so I don’t think it’s a major concern for most users. It doesn’t seem like something that can be fully mitigated either, so it’s probably not worth worrying about. Side channel attacks are really cool but also kind of useless in most practical scenarios.
tidderuuf@lemmy.world 3 weeks ago
Let me stop you right there… and leave.
NaibofTabr@infosec.pub 3 weeks ago
Normally I would agree with this perspective, but in this case the “malicious app” is just a demo. It requires no permissions to do the malicious behavior, which means that the relevant code could be included in any app and wouldn’t trigger a user approval, a permissions request or a security alert. This could be hiding in anything that you install.
krooklochurm@lemmy.ca 3 weeks ago
Man in the middle an app download or find some kind of exploit to inject the code from a website, ta da.
I mean, obviously there’s more to it than this but.
NihilsineNefas@slrpnk.net 3 weeks ago
So they’re using the same programs that the three letter agencies of the world have been using to crack phones since before touchscreens existed?
FreedomAdvocate@lemmy.net.au 3 weeks ago
So it could be hiding in, what would you call them…….malicious apps?
The relevant code isn’t going to be in a non malicious app.
hietsu@sopuli.xyz 3 weeks ago
Having cleaned a bunch of old folks phones in the past years this is far more common than we ”advanced” users think. It often starts with clicking an advert or some spam mail or message from (infected) friend, which to them, looks absolutely legit. Then the installed app spams the user with notifications to install more ”PDF readers”, ”phone cleanup apps” and whatnot. In best case these just flood the user with ads but just as easily can do more malicious stuff.
After some schooling (”never click anything that is offered to you” etc.) and putting up defencew like AdGuard (system level) the instances of ”my phone is slow”, ”what does this message mean” etc. have radically decreased. Apple devices have their own issues but this kind of troubles are next to non-existent there.