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

341–350 of 535 posts

Re: Android may soon restrict on-device ADB

#341

Post by rolph »

docmars wrote: post #295
wahnfrieden wrote: post #185

Earlier quoted context omitted.

Sometimes attacks happen from users being instructed to enable settings in order to achieve something regardless of whether you’d expect them to have a reason to use the setting

Then maybe the best course of action is Google adding a warning before enabling certain settings that help normies avoid these attacks. Along the lines of "Are you being asked to do this by someone else? Be cautious, as your device could become compromised."

its ridiculous how many people will ignore the warnings and relay the security challenge/solution to the attacker.

"we will never ask for this over the phone" takes second place to:

"we will send/save you money/time if you make it convenient"

dress it up to taste like developer needs, and you can hook the newbies.

Re: Android may soon restrict on-device ADB

#342

Post by kuschku »

izacus wrote: post #164
TeMPOraL wrote: post #79

Earlier quoted context omitted.

Anything can fit into CVE. "An app can bypass OS security system with certain setting enabled" is absolutely a valid CVE. We have countless examples every day of vendor apps bypassing OS security systems because they're allowed to do so. "A device can bypass protective layers and cause soft tissue damage when thrown" is an absolutely fine CVE, too. Whether it matters or is something that should be addressed, is the d…

Apps being able to bypass a restriction put on them by the OS always matter. Whether that means there's a _feature_ lacking there, is another question.

The OS provides restrictions and permissions so that the user can apply them to apps.

If the user chooses to free certain apps from restrictions, that should be their choice.

But if a piece of software overrides the users' choice, that certainly qualifies as a CVE.

This is an important distinction! The user must always have final say.

Whether an app breaks out of the sandbox and steals my vacation photos, or the OS sets new restrictions I can't remove, both are wrong.

Any piece of software has to act in service of the user, and ONLY the user. It must not do things or set restrictions without the users consent. No means no.

Re: Android may soon restrict on-device ADB

#343

Post by gruez »

zb3 wrote: post #299
gruez wrote: post #280

Earlier quoted context omitted.

>like uninstalling bloatware, denying apps internet access All of these can be done with a computer. >recording calls (legally).. A second phone does the same thing. >Hack for "escalating privileges" on my own device so I can do nefarious actions Whether it's a "hack" is orthogonal to whether you control the device or not. I don't think anyone disputes that you "own" your linux PC, but using the well known `docker ru…

> All of these can be done with a computer. Can you permanently apply chain3 (FIREWALL_CHAIN_OEM_DENY_3) firewall rules, so that when the device reboots these are still applied? I see no persistence. And if I'm forced to install some crappy app on-the-go, the solution you propose is to always carry a computer with me, right? > A second phone does the same thing. So does a Phonograph from 1877, right? > Whether it's a…

>Can you permanently apply chain3 (FIREWALL_CHAIN_OEM_DENY_3) firewall rules, so that when the device reboots these are still applied?

Just use firewall VPN apps + VPN lockdown mode (ie. "block connections without VPN").

>So does a Phonograph from 1877, right?

I think it's fair to factor in what feature was lost because wireless-adb-on-localhost was removed. If some critical accessibility feature was lost, that would be far more important than something that's merely a mild annoyance, like needing a second device to run `adb install`.

>I just pointed out how evil and malicious that privilege escalation on my own device is. Google must block it immediately, it endangers the mankind.

Right, but going back to the docker root analogy, would you think it's unreasonable if people threw a hissy fit of linux kernel/docker developers added some security feature that blocked it?

Re: Android may soon restrict on-device ADB

#344

Post by sgt »

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),…

Don't forget "Remember for 30 days" checkboxes that don't do anything.

Re: Android may soon restrict on-device ADB

#345

Post by gruez »

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.

That's a non-issue because you can build (or patch+resign) grapheneos yourself.

Re: Android may soon restrict on-device ADB

#346

Post by TeMPOraL »

izacus wrote: post #174
TeMPOraL wrote: post #105

Earlier quoted context omitted.

You forgot to ask yourself whose interests are being secured, and who/what is the threat being secured from. Security is not an unqualified good. It's just mechanism of control.

The users.

As the threat being secured against, yes.

Re: Android may soon restrict on-device ADB

#348

Post by inigyou »

atty wrote: post #186
wahnfrieden wrote: post #185

Earlier quoted context omitted.

Sometimes attacks happen from users being instructed to enable settings in order to achieve something regardless of whether you’d expect them to have a reason to use the setting

Sure, sometimes people get social engineered into taking money from their bank account and giving it to criminals. Should banks stop allowing withdrawals?

In Sweden the answer was yes.

Re: Android may soon restrict on-device ADB

#349

Post by [deleted] »

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),…

[deleted]

Re: Android may soon restrict on-device ADB

#350

Post by ignoramous »

kitsumed wrote: post #331
ignoramous wrote: post #49

The article overlooks security implications from spyware, which is a huge problem not only for financial applications, but personal safety, too [0]. Per FTC, a stalkerware will: geo locate, read call list & record calls, read notifications, texts, & possibly emails, access gallery, camera, & files, and monitor network activity. [1] You could do all of those with "on-device adb" (in some cases, with just the appropria…

Spyware using ADB could be a thing (assuming someone has full access to your phone, including the password). However, it is impractical, as a reboot, system update, or Wi-Fi change would likely break everything. It is much easier for spyware to be installed as a device administrator, granted accessibility privileges, and then given every possible Android permission via AppOps as a one-time setup. At that point, ADB n…

> spyware to be installed as a device administrator, granted accessibility privileges, and then given every possible Android permission via AppOps

Correct, and apps using these setups (even for genuine reasons) have been under the cosh.

> At that point, ADB no longer matters.

"on-device adb" wasn't meant for scenarios it is being used for (via Shizuku, for example). It is a pointless attack surface.

> anyone with physical access to the phone would still be able to install and configure their spyware via a USB cable.

This same case can be made in support of removing on-device adb. Anyone with physical access can install & configure for their use cases. If you claim that's more hassle than worth, then you have your answer (that is, added hassle for stalkerware sellers, too).

Disallowing on-device adb is restrictive (I co-develop a security app that can absolutely make more from elevated permissions, via Shizuku or Device Admin; let alone root), but I don't think Google will do so because they want to close Android (the platform) more than they need to. To me, given the very human costs of stalkerware & financial fraud, it is an understandable, even if disappointing, security decision. Otoh, I do get that the road to hell is paved with good intentions...

Post reply on HN