Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

Post reply on HN
Print view View original

351–360 of 535 posts

Re: Android may soon restrict on-device ADB

#351

Post by inigyou »

ryandrake wrote: post #305
zbentley wrote: post #289

Earlier quoted context omitted.

Eh, this is a tough conversation for engineering-minded folks because the right answer is probably somewhere in the middle of a few different variables. Too far towards trying to make mistakes impossible (which is easy for corporations to talk themselves into because it also makes them money and moat) and you make devices useless. Too far towards full user control and you get difficulties in support and security issu…

It requires a nuanced discussion and willingness to compromise to find the right balance. I don't like it myself when, every macOS release, Apple nerfs the system even more and locks down even more, but I also don't like telling my relatives that their system is part of a botnet and that they need to change all their password and call their bank, simply because they saw a popup that told them to download and run Troj…

It used to be common knowledge that downloading stuff could be dangerous. That went away when vendors tried to make it safe.

Re: Android may soon restrict on-device ADB

#352

Post by asveikau »

microtonal wrote: post #30

I am generally in favor of security improvements, but I do not really see much of a benefit here. This attack vector requires both that the user enabled developer settings and that they have remote adb enabled. So, this does not seem to be a realistic attack vector for 99.9% of the users and most of the other 0.1% probably know what they are doing. The other proposed change (to restrict access to certain interfaces o…

In the post iPhone era, a lot of what gets sold as security features is actually just removing functionality from the device.

In early days of this, I honestly think it was rooted in the famous Steve Jobs paranoia, the one that shipped without an app store and told users to use Safari, the same Steve Jobs that was said to not want certain medical devices during cancer treatment to touch him because they weren't beautifully designed. It was fundamentally about not wanting "dirty" things coming in contact with his "perfect" device. They dressed it up in language about security as a post hoc justification.

I remember in those days people would say they didn't want it to be like malware ridden Windows 98. But they omitted the weak security behind Windows at that time, which modern systems had long ago exceeded, even in the Windows world.

Re: Android may soon restrict on-device ADB

#353

Post by inigyou »

zbentley wrote: post #290
freedomben wrote: post #189

Earlier quoted context omitted.

Following this logic, shouldn't we just ban smart phones for everyone then? If we need to dumb down all technology to the absolute lowest level, we should probably ban computers or at least require an official government-controlled license to get access to one. Is this a world you want to live in? Me neither.

I suspect this is in bad faith, but assuming not: how does that follow? “Large numbers of people will uncritically follow sketchy instructions and get hacked” doesn’t in any way lead to “and therefore they cannot be trusted with devices”. “People keep dying in auto accidents” doesn’t imply “ban cars” on the first order, it implies “seat belts and airbags”.

Yeah well this new thing is like requiring a certified Ford driver to drive the car.

Re: Android may soon restrict on-device ADB

#354

Post by inigyou »

londons_explore wrote: post #118
xg15 wrote: post #114

Earlier quoted context omitted.

Told by whom though? If it's through proxyware, then there are three parties who mostly don't know each other: - the app embedding the proxyware SDK for money - the proxy operators - the attackers/botnets using the proxy to access ADB. The botnet has no access to the app, so it can't show any messages. The app can show messages, but probably has no connection to the botnet. (I hope) The proxy operators could show a m…

It isn't being done behind-the-back of proxy operators. It's one more revenue stream to be able to remote control real android phones to pass device attestation checks etc. It's marketed to users with phrases like "earn money from your phone whilst you sleep".

And it's entirely Cloudflare's and Google's fault. When you say you need to have X to do Y, people are going to find ways to get X.

Re: Android may soon restrict on-device ADB

#355

Post by inigyou »

Telaneo wrote: post #226
ryandrake wrote: post #209

Earlier quoted context omitted.

I think expert users on HN seriously downplay the ability and willingness of "regular users" to do very stupid things on their devices. If grandma wants that app that gives her a beautiful horse as a lock screen image, she will follow every one of those six steps that the malware HorseLockScreen app developer presents to her. She will tap a button that has a skull and crossbones icon, that says "tapping this will dra…

If the users' willingness to do stupid things is boundless, then locking down the system further isn't really of any benefit, since users will continue to venture as far as they need to, no matter the number of safety barriers they've passed. The only solution to that problem is a fully locked down device (which I hope we can all agree should not be the only option).

That's why they're going to fully locked down devices.

Re: Android may soon restrict on-device ADB

#356

Post by inigyou »

J-Kuhn wrote: post #159
izacus wrote: post #67

Earlier quoted context omitted.

"An app can bypass OS security system with certain setting enabled" absolutely fits into CVEs. There's no "depends: on it. I love how quickly you all forget about security and privacy when it gives a chance to angrily rant.

I changed the sudo settings to not require a password. Now an application on my computer can obtain root without user interaction. Where is my CVE?

Same. There are so many things you could mess up without root from my account anyway. My account isn't a locked down one. You could alias sudo to a keylogger, for instance, and then do whatever as root the next time I sudo something.

So the password check really has no point. Typing sudo is still a lightweight sanity check, otherwise I may as well just log in as root.

Re: Android may soon restrict on-device ADB

#357

Post by inigyou »

yyhhsj0521 wrote: post #178
izacus wrote: post #46

Earlier quoted context omitted.

The bug literally describes how they're avoiding OS security restictions by going through the debug port. This is a CVE by any definition and you'd be screaming your head off if any other OS would allow this kind of permission bypass (or even if another app did it). But sure, Google evil.

New CVE found in Bank of America app that may cause user to transfer money to hackers if they press certain combination of keys.

Actually that's what the whole fraud detection thing is about. If you transfer money wrong, they lock your account. Some countries like Sweden even went cashless so they can see all transfers.

Re: Android may soon restrict on-device ADB

#358

Post by inigyou »

NotPractical wrote: post #306
gruez wrote: post #225

Earlier quoted context omitted.

>What else should they have done? Use an AOSP fork like grapheneos or lineageos. Barring that, voting with their wallets and buying a HarmonyOS phone. If for whatever reason they're doing that too, there's probably more powerful forces behind this change (eg. government mandates) that won't be helped by spamming an issue tracker.

I have bad news for you if you think GrapheneOS isn't going to accept this patch from upstream if it lands.

Graphene would probably make it an option, like how it asks you if apps should be able to access the internet.

Re: Android may soon restrict on-device ADB

#359

Post by therein »

zaptheimpaler wrote: post #325
microtonal wrote: post #30

I am generally in favor of security improvements, but I do not really see much of a benefit here. This attack vector requires both that the user enabled developer settings and that they have remote adb enabled. So, this does not seem to be a realistic attack vector for 99.9% of the users and most of the other 0.1% probably know what they are doing. The other proposed change (to restrict access to certain interfaces o…

"Security" is just a scourge on software at this point. It means 2FA on every trivial site, being logged out every few hours for no good reason, having to fuck with settings and type "disable sandbox" to run an agent in YOLO mode which still won't work over mobile, being unable to install an unsigned extension at all in firefox (not behind a setting, literally impossible - you have to get Firefox Developer Edition),…

It is all so frustrating.

Reminds me of what Ubiquiti tried to pull a few weeks ago. They wanted to force everyone to their Cloud UI and login instead of the local interfaces so they reduced the local session lifetime to something insane like 20 minutes while lying to our faces and saying it is for security, and kept the session lifetime longer on their cloud panels. They made sure to exclude this from their changelog too.

The community started monkey patching their local scripts, wrote services to undo their changes, many people disabled auto-updates as Ubiquiti only makes their product worse with their updates. Publicly complained on their support forum that we are onto their little plot.

They ended up backtracking for now but you just know they will try again like Google does.

Post reply on HN