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

141–150 of 535 posts

Re: Android may soon restrict on-device ADB

#141

Post by redeeman »

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.

no, its a cve if the app can just do it automatically, it is NOT a cve that user goes through 5 steps that they very explicitly do, including unlocking hidden menus to open up developer options, and then allow it.

seriously, get real, please explain how your train of thought works here

Re: Android may soon restrict on-device ADB

#142

Post by Tade0 »

BoxwoodSeed wrote: post #102
daemin wrote: post #95

Earlier quoted context omitted.

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.

Currently my bank requires a device where I need to insert my card to get a one time six digit code based on a QR code the banking website serves me that the device scans. I'm not quite sure why they don't support something like a yubikey with FIDO, but maybe there's a good reason.

ING supports hardware keys in some markets, so there's no reason not to.

Re: Android may soon restrict on-device ADB

#143

Post by TeMPOraL »

cynicalsecurity wrote: post #92
ninalanyon wrote: post #80

Earlier quoted context omitted.

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

Follow up question: how many of those still let you log in and authorize transfers without relying on their mobile app as required second factor?

Re: Android may soon restrict on-device ADB

#144

Post by gnfargbl »

dns_snek wrote: post #108
gnfargbl wrote: post #94

Earlier quoted context omitted.

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…

> 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. This was proposed by a Google employee: https://issuetracker.google.com/issues/526109803#comment3

That link is mentioned in the article. To quote it:

> Connection to localhost has also been the source of exploit where app are using that socket to adbd to escalate their privileges. What about we restrict to always only binding to wifi interface wlan0 ?

Nowhere in that text do I see a proposal to assign an additional CVE for this behaviour. Personally I think it would be unusual to assign a CVE for intended-but-potentially-harmful functionality, although I expect people have done that in the past. But, I think overall we're agreeing here.

Re: Android may soon restrict on-device ADB

#145

Post by II2II »

crote wrote: post #119
pigggg wrote: post #40

Earlier quoted context omitted.

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?

It seems to require the user to: 1. Enable Developer Mode by going to an obscure settings page and tapping the build number seven times 2. Enable USB ADB debugging in the Developer Options 3. Establish an actual USB ADB session 4. Enable TCP/IP ADB debugging in the Developer Options 5. Unknowingly download a malware app from the official Play Store 6. Blindly click "Yes" on the permission prompt. In other words: this…

> In other words: this is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it.

Have you ever worked with someone who barely knows how to use a mobile phone? They will hand their phone over to someone they barely even know to do something they don't understand. They will follow instructions from a stranger over the phone, without understanding what the phone is warning them about.

I have worked with such a person. They did have someone walk them through a dubious process. Thankfully they realized what was going on before the process was complete, but who knows how much damage was done by the initial steps.

There are legitimate security reasons here. Whether there are reasons beyond that is an open question.

Re: Android may soon restrict on-device ADB

#146

Post by TeMPOraL »

dankobgd wrote: post #133

Can they ruin it faster i am sick of it already. Need to root the phone to get basic functionality, i need like 6-7 magisk modules to do basic things. I can't access file system on device i paid 250$. I have to use adb to change basic things, i rather use symbian.

> on device i paid 250$

It doesn't get better even if you pay 2500$, which is extra silly.

Re: Android may soon restrict on-device ADB

#147

Post by pigggg »

franga2000 wrote: post #137
pigggg wrote: post #40

Earlier quoted context omitted.

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?

You haven't been able to connect to an android device on port 5555 for yeeears. Every time you enable adb/IP it generates a new random port, or you need to use the QR/PIN pairing thing. On top of needing to enable developer options, adb/IP, confirm the fingerprint.

Millions of Superboxes and various digital picture frames say different.

https://synthient.com/blog/a-broken-system-fueling-botnets

Re: Android may soon restrict on-device ADB

#148

Post by stein1946 »

devsda wrote: post #27
satvikpendem wrote: post #8

Of course this was bound to happen, next you're telling me people will be surprised that the 24 hour limit for side loading will turn into some indefinite time period.

It can and will most probably turn to indefinite time depending on the answer to the question "will we have a viable alternative to jump ship before that happens ?". We don't need anything to completely capture the market, it has to be just enough to make Google hesitate or make it hard for Google to do it for legal reasons. Like how Firefox is ideally supposed to be for Chrome.

> will we have a viable alternative to jump ship before that happens ?

Here is a better question:

"Is the EU going to stop this?"

Re: Android may soon restrict on-device ADB

#149

Post by sunaookami »

stein1946 wrote: post #148
devsda wrote: post #27

Earlier quoted context omitted.

It can and will most probably turn to indefinite time depending on the answer to the question "will we have a viable alternative to jump ship before that happens ?". We don't need anything to completely capture the market, it has to be just enough to make Google hesitate or make it hard for Google to do it for legal reasons. Like how Firefox is ideally supposed to be for Chrome.

> will we have a viable alternative to jump ship before that happens ? Here is a better question: "Is the EU going to stop this?"

No because the EUDI Wallet needs Google Play Services. People need to come to the realization that the EU has no interest in regulating the freedom of devices because the EU itself is benefitting from the closed-down ecosystem.
Post reply on HN