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

91–100 of 536 posts

Re: Android may soon restrict on-device ADB

#91

Post by spaqin »

izacus wrote: post #46
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…

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.

In this case, the OS security restrictions should be questioned in the first place as excessive if a "backdoor" is necessary for normal function.

Re: Android may soon restrict on-device ADB

#92

Post by cynicalsecurity »

ninalanyon wrote: post #80
mnahkies wrote: post #71

Earlier quoted context omitted.

Unfortunately many banks in the UK no longer offer a web portal or physical branches. I'd love to see legislation that mandated a functioning web experience for critical services like this (banking, utilities, etc) - otherwise it will continue to further entrench the current duopoly. (I suppose this is also an instance where I should do a better job of voting with my feet and supporting services that do offer this)

> many banks in the UK no longer offer a web portal Same in Norway.

Poland, all banks I know offer web portal. Linux, Firefox - works perfectly.

Re: Android may soon restrict on-device ADB

#93

Post by TeMPOraL »

dns_snek wrote: post #90
TeMPOraL wrote: post #48

Earlier quoted context omitted.

> 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 perhaps they wouldn't? CVEs aren't holy scripture, and "security" isn't the most important consideration in computing. This theatre has gone too far IMO.

Allowing strangers to run adb commands on your phone without your consent is about as bad as a compromise can get. Your keyboard can be replaced with a keylogger and all of your data can be stolen without your knowledge by simply connecting to the wrong wifi network.

Yes, but what about allowing me to run adb commands on my phone with my consent, and especially delegating that privilege to "strangers", again, with my (one-time) consent - by which I mean authorizing apps to run with elevated privileges and/or reestablish the debugging bridge once it invariably disconnects (for other more or less legitimate security reasons)?

It's not like those threats silently turn on ADB on people's phones without their knowledge. You have to opt in to a rather obscure, hidden by default, and very fickle feature to become potentially vulnerable in the first place.

Re: Android may soon restrict on-device ADB

#94

Post by gnfargbl »

izacus wrote: post #46
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…

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.

You, and may of the people in the thread here are at cross purposes, I think.

The CVE mentioned in the article is https://nvd.nist.gov/vuln/detail/CVE-2026-0073. That's a real CVE: logic error leading to auth bypass. Fix can be seen at https://android.googlesource.com/platform/packages/modules/a....

Separately, a number of people here are attempting to argue that the availability of On-Device ADB should be regarded as a "CVE" in and of itself. Google does not appear to share that view.

Re: Android may soon restrict on-device ADB

#95

Post by daemin »

peheje wrote: post #42

We need Linux on phones. Bank apps not needed as long as I can use browser. But do need some things like wireless cards, popular apps like Sonos and Spotify working.

Unfortunately these days bank apps are required by the banks for "security", and good luck getting anything done without the bank app installed on your phone.

The only other alternative available is SMS but that is being phased out (rightly so) for being insecure.

Re: Android may soon restrict on-device ADB

#96

Post by xg15 »

> Scenario 3: A Developer Using ADB over TCP/IP

- You install a malicious application.

- You enable USB debugging, starting ADBD.

- You connect via USB ADB to enable TCP/IP, then disconnect the USB cable.

- ADBD continues running and listens on all network interfaces.

- The application initiates a connection, causing an authorization prompt to appear on the screen. If the user selects No, the connection is rejected. No silent exploitation attempts are possible.

I understand the author's rationale and think the reasons why that whole ecosystem is accessing ADB are legitimate - but I have some questions here.

The above flow is basically what apps that use Shizuku have to do as well, right? Only that in that case, the user would deliberately install the app and have the knowledge it uses ADB features and therefore would also confirm the permission prompt.

However, ADBD in this situation only sees a connection attempt, not which app made the attempt, right?

So it also cannot remember that a particular app was already authorized by the user and has to display the prompt again on each connection attempt?

Does that mean that a Shizuku-enabled app would prompt the user again for ADB access any time it's started?

This seems honestly like Shizuku itself would increase the risk of a user granting ADB access to a bad actor (i.e. a second app or external connection that is different from the app the user wanted to authorize).

Thinking of "scenario 3" if a Shizuku-enabled app is already running on the device and something else wants to connect to ADB:

- I'm assuming a malicious app was already installed (without privileges) or something tries to connect to port 5555 from outside or via proxyware.

- ADBD is already running and listening for TCP to serve the Shizuku app, so those steps can be taken for granted.

- The malicious app or connection triggers a permission prompt from ADBD. However, by that time, the user has grown used to those prompts, because the Shizuku triggers them frequently, so they are more likely to select "yes".

If ADBD has no information about who is connecting, it also can't show any meaningful information in the prompt. So it cannot really help the user distinguish prompts from the legitimate Shizuku app from malicious prompts. A user still has the timing and context to distinguish prompts, i.e. prompts that appear out of the blue when they aren't using the app are suspicious.

Re: Android may soon restrict on-device ADB

#97

Post by BoxwoodSeed »

rcMgD2BwE72F wrote: post #56
tonyhart7 wrote: post #51

Earlier quoted context omitted.

we can just fork android edit: I not realizing that I been replying to wrong comment

Ah yes, Android without the Play Store. So you won't be able to use your banking apps, your local transport app, public services apps, health services apps, etc. But sure, you can do SMS (no RCS though), use the device calculator, and maybe browse the Web… until websites kick you out because your non Chrome/Safari browser isn't supported anymore. Even Signal won't work well due to the lack of FCM. And I'm a GrapheneO…

I always disable everything Google that comes preinstalled other than maps, including the App store. You can download stuff that you can only get there through Aurora, but really most of what I use comes from F-Droid.

Not that I trust a device running Android enough to do banking, mind you.

Re: Android may soon restrict on-device ADB

#98

Post by PunchyHamster »

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…

It's not because of security. It's to slowly close any avenues for side-loading stuff

Re: Android may soon restrict on-device ADB

#99

Post by m132 »

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…

> This attack vector requires both that the user enabled developer settings and that they have remote adb enabled.

Not just that. A non-development Android build will also prompt the user when a connection is made to authorize the client's key.

This once again isn't about security of users, this is about security of the company's interests.

Re: Android may soon restrict on-device ADB

#100

Post by TeMPOraL »

vrighter wrote: post #88
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.

a lot of cves are of the type "if you leave the keys in the door, then anyone can unlock it and get in! We must destroy all doors, they are insecure!" This is one of them

You jest, but passkeys seem to have literally been invented to address something like: "Keys to your doors can be used by anyone to open those doors, regardless of your knowledge or presence".

Which is a problem only if the third party acquired those keys without your permission, but the industry decided to "fix it" regardless.

Post reply on HN