kitsumed

The person who made that suggestion ([email protected]) is presumed to be the one of the main maintainer of ADB as their name (Fabien Sanglard) showed up in non-redacted in the history and CC here (https://android-review.googlesource.com/c/platform/packages/...) after it was linked in the original Google IssueTracker. We can confirm they are a Google employee as per their @google.com top domain name. (For users reading, please don't target this person, it won't change anything AT ALL, i'm stating this since its public informations, and for proof)

Their email is also in the CODEOWNER of ADB, and they made the recent ADB Wifi 2.0 presentation at Droid-Con Paris.

They stated, "Connection to localhost has also been the source of exploits where apps are using that socket to adbd to escalate their privileges," which suggests that internally they viewed it primarily as an exploit bad actor uses. Without feedback, they would most lickly not consider changing their point of view, this is why the blog post was made.

The article shows that this is technically possible for bad actors to use it, assuming the user allow it, but highly unlikely in practice: https://kitsumed.github.io/blog/posts/android-may-soon-restr...

I do agree, however, that many of the comments, mainly on Reddit, blow the issue way out of proportion. Based on the website analytics, I can also confidently say that most people didn't even open or read the blog post. That's fine with me, though. My goal was to get the attention of actual developers and more technical users.

I have been very carful in the blog post not to write something too dramatic like some news outlets do, but if no one read it, I can't do anything about it.

EDIT: I have purposefully left that person name out of the blog post I originally made to avoid encouraging people to message them directly. However, if I need to update the blog or publish some kind of follow-up with supporting evidence, I may end up linking it. I'm not sure tbh.

The On-Device ADB work-arounds and a lot of open-source apps related to it are already in that fragile workarounds "zone".

For most, this is the last resort / only way possible. As AOSP refuse to add secure permission or services to allow third-party application to do specific actions.

If this get fixed, it will be the end of thoses project on-device for non-rooted ROMs. Sure, you could still run it via a computer, or to be far fetched, start Shizuku via a computer. But that's no longer "on-device". It kill a lot of usages, including developers who need it "on-the-fly".

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.

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 no longer matters. The spyware is already configured and ready to run. Even if on-device ADB were patched, anyone with physical access to the phone would still be able to install and configure their spyware via a USB cable.

As for attacks without physical access, as explained in the article with the 3 scenario, this is neither practical nor realistic. It only affects a very small subset of users (primarily Android developers) under very specific circumstances and during limited time windows.

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

Every ADB connection has some kind of certificate / key that is saved locally. This means that a new application would have a different certificate. That certificate is shown in the yes/no prompt.

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

You can tell android to remember that certificate and allow the connection next time. There is a bug that make it not work on certains specific version of Android 12 I think, but outside of that, it always works.

If I didn't word it like that (I'm the author) the "reddit mob" would have exploded the thread. That's the last thing I want. I want valuable feedback there, for now its somehwat working.

Most of the users who saw the post on reddit didn't even open the blog post anyways, according to analytics.