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

71–80 of 535 posts

Re: Android may soon restrict on-device ADB

#71

Post by mnahkies »

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

Re: Android may soon restrict on-device ADB

#73

Post by izacus »

roer wrote: post #61
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.

The original issue is proposing letting the user assign the debug service to a specific interface, one of which would presumably be loopback. This article is about the proposal from a developer that it should only ever be assigned to wlan0, which would break a lot of apps. Letting applications bypass permissions with this feature is the exact usecase they don't want to lose. If anything, I don't see them being agains…

It would break exactly 0 apps because none of the apps should be using this API to access your private data and phone call audio.

Re: Android may soon restrict on-device ADB

#74

Post by TeMPOraL »

RobotToaster wrote: post #59
TeMPOraL wrote: post #52

Earlier quoted context omitted.

What would that be useful for anyway? Sounds like something aimed to prevent people from reusing their old/secondary devices for IoT.

Hides memory leaks

Right, that too. But that's a reason to recommend regular reboots[0], not to force them, and "3 days of inactivity" is a suspiciously specific time that I also saw mentioned in Android settings somewhere the other day.

--

[0] - Which I find deeply ironic, in that merely a decade ago, people would laugh at Windows with its "reboot after installs, reboot in case of problems" approach, and now frequent reboots are seen as Standard Security and Stability Practice on *nix systems, both mobile and server-bound...

Re: Android may soon restrict on-device ADB

#75

Post by xg15 »

pigggg wrote: post #40
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…

Isn't this because of the kimwolf (and now 6+ other botnets) that are taking advantage of people running residential proxyware unknowingly on the device which permits outbound connections to 127.0.0.1 on tcp/5555 to auth in and exec wgets or drops a loader that grabs the ddos malware APKs and install it?

Hadn't thought about that additional attack vector those proxies are enabling. In addition to "internet access from residental connection" privileges, the attacker also gets access to loopback on the device that does the proxying...

But even then, shouldn't this show the same permission prompt for the user that anything else trying to connect to port 5555 would?

Re: Android may soon restrict on-device ADB

#76

Post by rcxdude »

izacus wrote: post #67
theplumber wrote: post #53

Earlier quoted context omitted.

Depends how you define a CVE. If owning and controlling your device is a CVE/bug then sure you need a tight box with anti tempering as well.

"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.

When half that security is aimed against the user it's pretty easy to cheer for cracks in it.

Re: Android may soon restrict on-device ADB

#77

Post by bpavuk »

RobotToaster wrote: post #54
microtonal wrote: post #35

Earlier quoted context omitted.

Many alternative AOSP-based systems work fine today and do not have the new Android Developer Verifier (wow, already rolled out to 500M+ devices [1], though still dormant). To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones. Of course, we all knew that, but it highlights again that Google can remotely take away functionality that you had before, brick y…

We used to call programs like this, that allow someone to remotely break your system, a Trojan horse...

and now people install Remote Access Trojans just to let GPT and Claude think and work for them, granting them shell and a11y access. really? after seeing that, nothing surprises me

Re: Android may soon restrict on-device ADB

#78

Post by dns_snek »

theplumber wrote: post #53
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.

Depends how you define a CVE. If owning and controlling your device is a CVE/bug then sure you need a tight box with anti tempering as well.

Can you provide a reasonable definition where an authentication bypass in ADB doesn't qualify as a vulnerability? Is there a use case for allowing anyone on your network to run adb commands without your approval?

There are 3 things which I feel like are being confused here:

1. There was a genuine authentication bypass vulnerability in ADB (bad)

2. Initial proposed change wants to add an option to limit the ADB server to certain IPs or network interfaces (good - it doesn't affect you)

3. Response to the original request, proposing that ADB shouldn't be allowed to listen on loopback interfaces (bad/nefarious - it breaks functionality)

[1] https://nvd.nist.gov/vuln/detail/CVE-2026-0073

[2] https://issuetracker.google.com/issues/526109803#comment1

[3] https://issuetracker.google.com/issues/526109803#comment3

Re: Android may soon restrict on-device ADB

#79

Post by TeMPOraL »

izacus wrote: post #67
theplumber wrote: post #53

Earlier quoted context omitted.

Depends how you define a CVE. If owning and controlling your device is a CVE/bug then sure you need a tight box with anti tempering as well.

"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.

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 depends part. Here we're talking about CVE that's at risk of trying to address a feature.

You are forgetting the most important questions of security, without which the whole discussion becomes pointless:

Who is securing what, and from who?

CVEs seem much less like holy writ when they're aimed at protecting the device for commercial interests and from the device owner.

Re: Android may soon restrict on-device ADB

#80

Post by ninalanyon »

mnahkies wrote: post #71
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 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.

Post reply on HN