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 or IP addresses) seems good, but why not allow developers to restrict access localhost?
It reeks of trying to block Shizuku, Canta, etc. using a way that only makes it look like a side-effect.
"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), sites spamming me to get passkeys which will no doubt be declared insecure and replaced by some more moronic thing when users find a way to get hacked with those too, 80 layers of access control/service identities/IAM/Oauth to host an S3 bucket, OAuth everywhere that won't even work on a headless device, banking websites that want their own special snowflake app as 2FA instead of using TOTP, banning VPNs and slowly rolling out completely real identity surveillance on every corner of the internet to "protect the children", ban open-weight models because the numbers are going to send your data to China, and it just goes on and on and on..
When is this insanity going to stop? I really think the IT security industry ought to be ashamed of itself. Security has become a totalizing value that trumps every other value - convenience, user-friendliness, privacy, hackability, openness, just anything at all in the name of MORE SECURITY.
There is a simple and highly accurate heuristic to tell if a security measure is reasonable:
Is it an open standard that anyone can permissionlessly implement?
When the answer is yes, there is a high probability that it's something reasonable, e.g. TOTP.
When the answer is no, what you will find behind the curtain is either a fool or a crook.
This heuristic is not covering the dimensions of interest here, because it fails to address the key security questions (that the industry usually wants people to not even think about):
Who is doing the securing, whose interests are being secured, and against who/what?
Security isn't an unqualified good thing to have. It's just an instrument of control. Who wields it and how are the paramount questions. You can have an "open standard that anyone can permissionlessly implement", aimed at protecting interest of third parties, by securing the device from its actual owner. In fact, that describes many, if not most, security measures introduced in computing over the past 20 years, especially on the web and mobile devices.
Right, and that leads us back to the more-generalized (but very classic) cui bono? Who gets the benefits?
All this boils down to governments wanting security from their citizens and corporations wanting security from their customers. It's not going to stop, ever.
Taking this attitude, it's guaranteed.
Don't forget "Remember for 30 days" checkboxes that don't do anything.
> 2FA on every trivial site
But it helps against account sharing, err I mean they make database leaks irrelevant except for private info of the customer, err I mean that we can now send more mail to the customer about new AI features without risking they think it is phishing, err I mean this is the easiest measure for the auditor findings so since we implemented this we don't need to fix all the crappy internal api auth problems and atrocious out of date dependencies, err I mean...
> But it helps against account sharing
This is actually a feature, very common in real world, that security maximalists keep insisting is a bug.
IT has always been a spectrum with security at one end and convenience at the other. There is no recent trend that’s changed that. That’s just how life works.
Right, but security maximalist are running the asylum now, and they try to sell everyone the lie that more security is possible.
Also, the original sin: framing it as "security" vs. "convenience". It's not. The other end of the spectrum is utility - as in, maximally secure computing device is an inert rock. More security means less utility - reduced functionality, constrained capability, reasonable use cases no longer possible. It means manual process where previously automation or batching was possible. It means more electricity, more compute, more money spent.
It means more user time and therefore more human lives wasted.
This ultimate non-renewable resource is what we're trading off when we accept even more security. This trade-off needs to be respected much more than it is.
> Right, but security maximalist are running the asylum now, and they try to sell everyone the lie that more security is possible.
That’s not what’s happening. Here you have security used as an excuse for vendor lock ins. Just like AI is used as an excuse for layoffs. But you shouldn’t confuse actual security with BS like this.
"Better things aren't possible" is a terrible outlook. There have been real improvements in this space, such as passkeys, and recognition that some of this stuff, like frequent password changes, is counterproductive.
> Better things aren't possible
Literally no one in security thinks this.
I really think the IT security industry ought to be ashamed of itself.
See Pournelle's Iron Law of Bureaucracy.
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.
> 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.
Google just got hit by yet another record antitrust fine by the EU [1]. But as long as they see these fines as cost of doing business, nothing will change. Especially if it always takes almost a decade to push this through the judicial system. Their net income last year alone was $130 Billion.
[1] https://www.reuters.com/world/eu-top-court-dismisses-google-...
Eh, that is if they pay. Trump already made threats for tariffs in regards to those fines.
Which is a federal sales tax against the citizens of the United States countries abroad do not pay no matter how many times taco lies.
You're splitting hairs in this case, while that's unquestionably true, it's irrelevant if there tariffs are only set on one party.
That's why Trump's tariffs on everything was so ... Uh ... "Interesting". If only one party gets the tariffs, you end up with other parties selling the goods instead, which does cause meaningful damage to the tariffed party
Or the tariffing party just continues buying very nearly the same amount of things at higher prices in many categories because those items don’t have perfectly elastic supply and demand.
Technically true but highly misleading. The amount of good like that are few, less then 30% of the EU -> US trade.
That’s actually kind of like not a good statistic though.
For 30% of transactions with the EU it’s just the US shooting itself in the foot and passing on higher costs to average Americans.
Imagine enacting a tax where 30% of the money collected was a net negative. I can’t think of many taxes that are that poorly constructed.
For the 70% of transactions where US companies and individuals decide to buy less or use alternative sources, doesn’t that at some point harm US businesses? At the very least you’re now artificially lowering competition, which tends to drive overall prices up and quality down.
The EU shouldn't be regulating Google like this.
The US should.
The DOJ brought an antitrust case against Google… and won.
Then the judge pretty much decided “no consequences”.
It was the lamest excuse ever.
Something like, "I'm worried about impairing Google's ability to compete in AI" or some nonsense. (Paraphrasing here.)
Looks like all it takes to compete in AI is to issue stock or get a bunch of investors. I don't see how Google would struggle with that. It's completely orthogonal to antitrust enforcement.
Why not both? Countries should be able to signal which business practices are undesirable.
The EU can't realistically bring Google to its knees. The US could.
I say that as a European that's very much in favor of government intervention to fix market distortions.
Yes, laws are laws but one affects a branch, the other a root.
Cut off enough branches and the roots die.
Hopeless. US already lost against corps. And that will be their downfall.
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.
Hard disagree. iPhones are some of the most secure devices available. They are much more secure than desktop computers. This is a good thing because it protects users private data. With how much personal data phones, it seems reasonable to secure them extensively.
That's why I use GrapheneOS.
It's a security theater but you should at least respect that the guy was willing to die for beautifully designed devices and rid us of Adobe Flash.
> you should at least respect that the guy was willing to die for beautifully designed devices
I don’t think that kind of stupidity warrants respect.
This. I'm a developer, I've published Android apps, & I've still managed to lose access to a device that had dev settings enabled purely because remote adb enablement is a (extremely fiddly) toggle that happened to be off on the device at the time the screen broke. Having these two enabled simultaneously is such a rare case in the wild as to be entirely negligible as a vector.
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.
[dead]
If someone is willing to click on build version 5 times and then gets a mystery prompt about dev mode, and still goes along with the next 4 steps I think they were gonna get hacked a billion different other ways
The solution to social engineering can't be to remove useful features - you can socially engineer people to do literally anything, you can have someone walk to their bank, withdraw cash & fly to you with it with a dating scam: there are literally no boundaries once you get into that area of security. Digitally, you combat that through UX, messaging & education.
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."
Nobody reads the warnings and getting to use ADB on a phone is already a quest of epic proportions, soon to become the next Monkey Island sequel.
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.
> "we will never ask for this over the phone" takes second place to:
Doesn't help that the banks then do, in fact, call you, and ask for this over the phone.
those banks that do that are grooming customers for failure, they create a workflow that is close to an attack.
in my region AT&T has a very explicit statement not to reveal MFA codes to anyone who asks, is not part of thier system to do that.
there is 1 bank in my area that does voice call relay over the phone, the others keep it 10 fingers relayed from phone to authentication form.
guess who has the most problems with account compromise, and fraud claims? yes, that one bank. it has a phishing vector in its system.
Sometimes people fall down the stairs in their own homes. That doesn't mean the government should mandate everybody to wear helmets at home does it?
A measure needs to be in proportion to the actual risk it seeks to mitigate.
I am not in favour of limiting adb access, but this does beg the question, how many accidents would it take to cause enough overfull ERs to make the requirement of staircase railings a thing, in order to make sure there are doctors to treat other things than broken bones. uh happy Saturday.
In many jurisdictions, staircase handrails are required[1] in residential homes.
And even when they are required, it's up to the person using the stairs to determine whether they wish to elect to use the handrail or not.
[1]: IRC R311.7.8
Well in my book it is a cost vs benefit question. Handrails are not expensive in comparison to a medical procedure, nor are they particularly hindering in the daily use of the stairs. In fact, quite the opposite: anybody who uses stairs without handrails may find themselves temporarily disabled, e.g. if a circuit breaker tripped and you have to walk down the stairs in the dark.
That means, handrails cost little and have nearly no downsides. Which is why I used helmets as a metaphor. The proposed restrictions has a lot of downsides to deal with a mostly theoretical risk.
I think that these victims are paid by the likes of Google to create a precedent. It is unbelievable stupid scheme to fall to.
While I certainly think we should not be taking features away from people just because there exist people who will let themselves be social-engineered through arbitrary hoops, don't go creating wild conspiracy theories to explain something that supports much simpler explanations instead.
It's easy enough to imagine that Google is trying to fix something they see as a problem, and not caring about the developer case rather than specifically seeking to destroy it.
When Apple fixed security issues that allowed for jailbreaking, they weren't doing it specifically because people use it for jailbreaking, they were doing it because it was a security issue.
We should have 100% control of our own devices. But we should have it by design, in a fashion that makes sure that we control them rather than other people.
... and it is stupid to try to protect cretins who would do that by screwing everybody else.
[dead]
"In a normal scenario, a bad actor cannot gain an ADB connection."
It depends on how you define a bad actor.
"rootless privacy tools based on Shizuku."
It's not for the security of the owner; it is for the security of the government.
Trusted execution environment applications like the EU Digital (Identity) Wallet, or whatever they will demand next to protect the children, heavily rely on the fact that users cannot mess with their devices or install unsanctioned software. We all know how badly the Intel SGX story is going.
> why not allow developers to restrict access localhost?
Ads and tracking, obviously (https://localmess.github.io/)
All these changes Google is doing to Android aren't for you as the user, they are to protect their business interests from the user.
It seems to me a lot of Google lately is to block things they don't like using ways that only look like side effects.
The introduction of Manifest V3 API in Chrome for extensions, and disabling Manifest V2 for security reasons. It just so happened that ad blockers were made incompatible with the Manifest V3 API. It's a little blatant considering this came right around the time that YouTube began showing warning messages to users with ad blockers...
Requiring developers to verify their apps via Google Play Developer Console and blocking any unverified APK installations. This is done in such a way that it just so happens to squash F-Droid and most FOSS apps for most people, and blocks any serious competition to Google Play or any apps they don't like.
Of course, there's all this talk about preventing malware, but it is a fact that if you download any random ringtone or PDF app on Google Play it's going to come with probably 25 trackers and send your data to every jurisdiction in the world, and many apps even fail to declare any of this via Google Play data safety or privacy policy. Let's not forget that spyware is a form of malware. Take a look at the leaderboard :) https://reports.exodus-privacy.eu.org/en/reports/list/?filte...
In my opinion, this would probably be an indication that maybe Google controls too much technology and that they may need to be broken up to ensure fair competition. For Christ's sake they almost broke up Microsoft not that long ago for shipping a browser with their operating system, and now Google is blatantly controlling the operating system, the platform and app store, the ecosystem, the browser, the ad network, and abusing their power over it however they can.
I still can’t believe that an advertising company was able to effectively neuter ad/content blocking for 80% of the world under the guise of wholly invented safety issues.
uBlock origin and Brave shields work great. Never had a problem.
They wouldn't have been able to if people didn't use a browser created by an advertising company.
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 is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it. And it only works if the Play Store is useless at preventing malware in the first place - but I thought their excellent app scanning was the entire reasoning behind all-but-banning 3rd-party app stores and sideloading???
It is "for safety" in the same sense that governments banning all encryption is to "protect the children" or to "prevent terrorism": flawed justification invented to distract from the real reason they want it.
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 drain your bank account and kill your dog" if she thinks it will let her do whatever she's trying to do on her device. Have you guys never done IT tech support for your elderly parents' computers?
I'm not saying it's right to respond by simply locking everything down, but let's not downplay the blast radius of basically every attack that involves telling the user to do things.
A long time ago, I fixed Windows machines for pocket change. I can confirm some users will make bad decisions no matter what warnings they're given.
I think the impulse for an OS vendor to try to make such mistakes impossible is about as wrong as selling knives dull so people can't hurt themselves. A knife that can't cut its user is useless as a knife.
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 issues (which are tractable if you’re an enthusiast, but not so much if you’re a normie on a corporate-maintained device).
Truthseeking here is further complicated by ordinary end users’ dislikes and usability issues not always overlapping.
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 TrojanHappyFunGame.
It used to be common knowledge that downloading stuff could be dangerous. That went away when vendors tried to make it safe.
Many software vendors have deliberately blurred the lines between "on your computer" and "on the internet". When you save something in Application A, is it really being saved on your computer, or is it in the cloud? It used to be obvious, but now you kind of don't know until you do some digging in your filesystem. And, now we actually run some apps from the web!
The phrase "the user doesn't have to know if this is on his computer or the cloud" has done a lot of harm to the software ecosystem.
> Have you guys never done IT tech support for your elderly parents' computers?
This kind of comment is frequently made on HN and elsewhere. However, more than a few "elderly parents" are as computer-sophisticated as their grown children. A safe bet it's not rare to be exchanging ideas with an elderly person sophisticated enough to make comments on HN.
AFAIK there's no shortage of careless, uninformed, non-elderly individuals who get scammed into doing stupid things. Age is only one possible factor out of many contributing to scam vulnerability. And let us not forget that youthful, well-trained professional IT workers, developers and software engineers are not immune to scams via misunderstanding elements of the systems or processes they supervise.
"Ageism" is a word as ugly as what it signifies.
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.
So, they will use other vectors, like convincing people to transfer money. Set up fake webshop. Run scams through online marketplaces, etc. The solution is not to make everything impossible. The solution is to educate people.
Right, and for the few people who can’t be educated, there’s always the option of making dedicated idiot-proof devices. Some people need to wear helmets and knee pads while walking around, but that doesn’t mean that all of us do. Some people shouldn’t be allowed near sharp objects, etc.
Stop trying to flatten the human experience, Harrison Bergeron style.
Until they will look indistinguishable from regular businesses doing regular marketing, advertising, and "value engineering" bullshit. It's xkcd://810 of the advertising industry, I guess - all the scammers doing the legitimate, sanctioned scamming like one big happy family, instead of unfairly competing.
Well the messaging we’re told is that the google play store exists for safety - such an app would never exist on there.
Of course this isn’t true, the play store, and yes even the apple App Store to a lesser extent, is riddled with malware.
But what this demonstrates is that, clearly, Google doesn’t care too much about security or safety. It’s a pretense, not a goal. If it was a goal, they’d dump money into fixing the play store, but they won’t and they don’t.
So, we should be highly skeptical when they say something is for “safety” and “security”. At this point, it’s a lot like saying something is for “national security”.
On multiple occasions I had trouble getting people to accept a self signed cert to show them something on a local webpage. It seems that elderly nowadays are super vary of any hacking or scams. YMMV.
Excellent, security education is working. The correct response to someone trying to convince you to accept a self-signed certificate is extreme skepticism; don't undermine people's understanding of good security practices.
> It seems that elderly nowadays are super vary of any hacking or scams. YMMV.
I'm sure you meant "wary". How amazing, education really does work. There is such a thing as overabundance of caution. But it's possible further education could encourage users to apply more balanced caution policies.
> let's not downplay the blast radius of basically every attack that involves telling the user to do things.
That radius would be negligible should the things that must remain secret remain offline.
But no, that's a luddite thing to even think about in an all-connected ever-online world where even wiping one's ass is done via of a swarm of dedicated apps.
On the other hand, there has always been a way to extract secrets from a granny via a mere voice call, so no amount of dumbing it down would really help.
This gave me a hearty laugh not only due to the idea, but because that's been my near exact experience with helping my family.
> 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.
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.
On the contrary, we should simply restrict app development to a handful of megacorps (who are all in bed with the government) so they can make more money and the government can get the data it wants. Problem solved!
Me personaly, I'm so fed up with these advocates of security-through-universal-presumption-of-imbecility!..
> ban computers or at least require an official government-controlled license to get access to one
People seem to be ok with needing a license to operate a motor vehicle and those are far less dangerous.
Cars are far more dangerous and they kill people. It’s the number one cause of death for some demographics in the US.
A lot of people are misconstruing what I have said, which is pointing out that this can impact regular users. It not intended as a justification to restrict on-device ADB, and it certainly isn't meant to justify more extreme measures. That being said, we should not ignore what happens in the real world since the consequences are real.
Can we freaking sell them dumbphones, then, and stop destroying portable computers for everyone else with that excuse?
Which incidentally is often just a pretense for other motives?
If computers have suddenly become so dangerous for normal people, and they want smartphones nonetheless, add to them a dumb-mode encouraged at the initial setup, and requiring some third party assistance to turn it off once enabled..! (and forbid apps to change their behavior if it's not enabled)
Lots of dumb phones are trojaned on a firmware level. Trojans are different, but in general they allow the third-party (malware author) to accept SMS and forward them over internet. This is used to register accounts on a services which requires a phone number.
Here's my article about that from 2021. It's for the devices sold in Russia, but this issue is worldwide: https://habr.com/ru/articles/575626/
And here's more detailed research of two particular devices: https://notes.valdikss.org.ru/trojan-digma/
"Can we freaking sell them dumbphones"
Nothing is stopping the guy at Walmart or Tmobile from selling them dumbphones, or are you implying they are forced to?
Try letting the blame trickle down from the pyramid's apex instead of blaming the footman.
Here is the first iPhone ad:
https://www.youtube.com/watch?v=6Bvfs4ai5XU
The ad depicts it as a mere phone instead of a potentially hostile Turing machine. There is equivalent messaging in the android ecosystem but its advertising is not so ubiquitous.
You are right, better locking them out of the Play Store, there's too much risk using it.
We could also imagine a 24h delay to get Play Store access with a modal to make them understand the risks.
Those people will be conned in a million other ways.
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
Kimwolf exploits vulnerable Android Debug Bridge (ADB) services. Many low-cost TV boxes come "pre-infected" with proxy SDKs; Kimwolf then scans these residential proxy networks and exploits the devices within minutes as it propagates.
https://www.cloudflare.com/learning/ddos/glossary/aisuru-kim...
This is like saying that SSH is insecure because some device vendors install SSH, permitting root login with a default password of 'root'.
Yeah let's block port 80, too many people expose unprotected api.
This is what several cellular ISP to (block ports <1024 and 5555) to protect the users on IPv6.
You can unlock it with additional free option.
Well yes, but those won't get Google's new updates either. Open ADB on 5555 was a problem we solved almost a decade ago and these devices are still vulnerable. Even further restricting ADB in the latest version won't do anything to prevent that.
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?
Yes, but users are told to allow it if they want to get free coins etc.
You can't fully protect people from the risk of taking bad advice from malicious strangers.
Not the least because most of our industry relies on it to make money. Marketing and advertising themselves are institutionalized forms of "do this thing that's actually harmful to you to get free coins / be safe / get laid".
> Not the least because most of our industry relies on it to make money.
I mean, this seems more like one of the root causes for a lot of bad things in the industry me...
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 message by abusing the SDK even more, but that would mean they actively colluded with the botnet. Is that likely? Then they could just give the botnet direct access to the app, no need to do the whole proxy thing.
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.
Ok, that makes more sense. Hooray for stuff getting even worse...
Remote attestation itself being a questionable idea at best, so it's bad things creating a market for even worse workarounds.
No objection there.
Also telling that advertising and locking down devices are driven by the same companies...
From memory, for the kimwolf exploit things, other user already had good points about the device already beeing compromised. But also, the authentification part of ADB was just completly disabled, which is why this worked. Basically it was so-compromised as-is that ADB was just sitting here open, as is you where to put SSH with no authentification at all.
There are so many people in my neighborhood here that are actively members of residential proxy networks that it makes me stabby. They don't seem to care.
That said, I wasn't under the impression kimwolf was that technically sophisticated. Some of the others are, though.
It's not because of security. It's to slowly close any avenues for side-loading stuff
It's not side loading. Word you are looking for is called "installing".
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.
There's a vulnerability in my bike - when I push my left handlebar hard forward when riding down a road, I can crash into a pillar.
I think a possibility of knowingly pushing the handlebar should be removed from me, just in case. After all I could do it.
And while we're at it I just realised my car has a similar vulnerability, but triggered by a slightly different mechanism, but the effect is exactly the same, I can crash into a pillar.
Edit: oops, I just discovered that if I have a banking app installed on my phone, then tap my screen in the specific places, enter several numbers, including the number I receive in text, suddenly I lose all the money.
That's staggering!
I mean, you made a good metaphorical case for controlled handlebar slop/headset resistance in bicycles/motorcycles. Which are things that exist to mitigate crashes from oversteering on both of those vehicles!
In the bikes they're mostly aimed at preventing tank slappers/death wobble. I have a dampener on my bike myself, but it still allows me to countersteer as harsh/rapidly as I want, and that means crashing into a railing or a cliff wall if I overshoot.
No technology prevents the crash, they just lower the chance of it happening accidentally (like, say, ABS or DCT). I can remove almost all of the guardrails on my bike choosing more aggressive riding mode.
Countermeasures to the accidentally allowing a malware to "do something" already exist and were described in the original article. The comment I was responding to wants a removal of the whole capability, hence my cases.
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.
> 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.
Yeah, they didn't claim that it's a CVE, just behavior that they wanted to change. Miscommunication then.
>>I use loopback ADB daily to automate scheduling eye care display settings using settings since my OEM does not provide advanced scheduling routines.
>Which OEM do not provide this feature? This hardly quality as a legitimate usecase but rather as a shortcoming of the OEM.
I find this kind of attitude maddening. Although I assume they overlooked "advanced" because as soon as I read that, I knew this wasn't going to be something ever supported as a basic functionality. I get that many people will be fine with simple things but I hate being forced into them.
> 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.
They're 3 separate issues. There's a genuine vulnerability (CVE) which has been fixed, there's a follow-up proposal to allow the user to choose which interfaces to bind to, and there's another proposal to disallow ADB over loopback which would cut you off from using ADB on-device.
Your problem is with the last one which has nothing to do with the CVE itself.
Correct.
That, and security maximalism displayed in 3. and some comments in the HN thread.
I agree with user TeMPOraL in his comment. Those who aren't trapped in tunnel-vision, know the app permissions themselves have ALOT of access to all data on your device and users give the apps these permissions. Should we say that every app is a CVE? The real reason any Google dev wants ADB gone is to close open source and lock down the OS to Google sign-ins and a proxy proprietary closed source eco-system. ADB is the master-key to rooting Android devices, getting Android shell access to /root, uploading *.apks, etc... But for the Google monopoly, it makes sense to them to close/restrict this access, then funnel all requests for it through Google's identity gateway for access. So the argument "this app can bypass OS security through ADB and is therefore a CVE" is not valid and an foolish from its /root.
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
The act of "allowing“ negates the “without your approval“. You see the failure in the logic here I hope.
I thought we were having a technical discussion not a linguistic one. Baseline level of technical understanding is expected. s/allowing/enabling/.
allow [intransitive verb]: to make a possibility
https://www.merriam-webster.com/dictionary/allow
"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.
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.
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
This is not one of them. This is "the lock accepts any key" type of CVE.
> In adbd_tls_verify_cert of auth.cpp, there is a possible bypass of wireless ADB mutual authentication due to a logic error in the code. This could lead to remote (proximal/adjacent) code execution as the shell user with no additional execution privileges needed.
Patch: https://android.googlesource.com/platform/packages/modules/a...
Docs:
> EVP_PKEY_cmp() return 1 if the keys match, 0 if they don't match, -1 if the key types are different and -2 if the operation is not supported.
The original code cast the integer return value to boolean, and -1 and -2 cast to "true", therefore authentication would succeed if the key types were different or the operation wasn't supported.
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.
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.
When half that security is aimed against the user it's pretty easy to cheer for cracks in it.
Sounds like the Settings panel is a CVE, we should immediately get rid of it. And don't forget the Play Store!
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 against the original proposal possibly restricting non-loopback access, which would enhance security.
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.
So why do Google Play Services, etc. have full privileged access to a phone, including private data and phone call audio, but the user doesn't?
It is tech feudalism - you don't own anything anymore, you just get to live on the digital land of a bunch of ~trillion dollar companies.
At least, that is the goal.
IMO either everyone gets access at the user's discretion or Google has to sandbox their own GMS services as well.
Why? What other APIs should my apps (or the apps I explicitly want to authorize for this purpose) use to access my private data and my phone call audio?
So what official API call recorder app can use?
Because you know, the actual solution would be to have more granularity in authentication process than "allow whole device to attach to ADB", but that would be like, difficult... so they're not going to so that.
Right now any app on my PC connected to ADB could manipulate my phone then, and that's somehow not a CVE?
Is it a CVE that an app running on my PC could actually be running under GDB? It's the entire purpose of these tools.
In this case, the OS security restrictions should be questioned in the first place as excessive if a "backdoor" is necessary for normal function.
I am not sure I follow. Are you referring to the original CVE (?), I fully agree that it should be fixed, and it is not what my comment was about.
If you are talking about allowing listening on localhost - remote ADB requires enabling in the developer settings. It is a developer feature, similar to ADB over USB. If I'm charitable, it is possible that they are seeing too many people that are using Shizuku without understanding the security implications. But Shizuku has a lot of useful applications and they use ADB because the Android APIs and permission system are lacking and do not make these applications possible.
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.
More like if you have some settings enabled someone on your network can do it for you without your permission
More like the credit card company can initiate automatic withdrawals from your bank account without your permission if you previously authorized the company to do autopay.
"...avoiding OS security restictions by going through the debug port..." the user delibretry opened and paired to app with clear visual confirmation in order to use it.
Even if you have to deliberately enable a setting and enter a pairing code?
It's like saying that the fact the user knows their own password is a vulnerability because they might enter it to log into their account.
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