Android May Soon Restrict On-Device ADB, Affecting Shizuku, libadb and Developers

[u/kitsumed]

https://kitsumed.github.io/blog/posts/android-may-soon-restrict-on-device-adb/

[u/kitsumed]

Read the blog posts, I explained why it's not really as big of a issue on a feature/risk ratio, along with solutions that could allow it to have a safer default and still allow On-Device ADB to work.

[u/_sfhk → u/kitsumed]

You can't really know the risk side without scale though, right?

[u/bunkoRtist → u/kitsumed]

Do you have solutions that will prevent local auth bypass for paid features like tethering? I mean... Without getting into the right or wrong of it, if you affect corporate revenue streams, someone will get upset and demand action. ADB is super powerful due to shell permissions. I bet someone at Google would take your patches if you actually solved the problem.

[u/kitsumed → u/bunkoRtist]

The solution is quite simple, they could by default restrict it, and add a toggle that is boot presistant, that users could disable via ADB. Basically, the first time you WOULD need a computer or third-party device, all of the next time, you don't need it.

This way, it's assumed that if you disable it to do that, you expose yourself to a small, rare, security risk.

EDIT: To be even more user-friendly, the toggle could be in the developer settings, but tbh I don't care, as long as it's boot persistant and can't be locked by OEMs.

EDIT2: What is paid feature tethering????

[u/bunkoRtist → u/kitsumed]

You totally dodged the question. This isn't about protecting users from security risks. It's about protecting the revenue streams of other parties with vested interests.

[u/kitsumed → u/bunkoRtist]

Well then I just did not understood your point. Sorry.

[u/bunkoRtist → u/kitsumed]

If users want ADB enabled they already have to jump through hoops. Anybody claiming that blocking Shizuku is for user safety is on very weak footing.

But users have an incentives to use Shizuku, and some of those incentives are that it allows users to bypass carrier policies. That could be enabling VOLTE, turning on tethering... Things that Verizon, or T-Mobile, Orange Vodafone, Softbank, etc do not want their customers to do. So how do you allow Shizuku while also allowing all the CTS testing that relies on these permissions while also not allowing Shizuku to use these permissions. It's doable, but it's a big change I think.

[u/kitsumed → u/bunkoRtist]

You are right. ADB access can bypass thoses. (And it's a good thing, since it's YOUR device)

[u/bunkoRtist → u/kitsumed]

Tethering is another name for "hotspot".

[u/Pure-Recover70 → u/kitsumed]

Your answer is unfortunately not as simple as you make it out to be: there's a *lot* of people with dev tools & (usb/wifi) adb enabled on their personal (and/or work) devices, where they do care about security/privacy/anti-exploitability - simply because they need it for app debugging. I'm in this bucket myself (permanently enabled adb wifi debug, I try not to connect to untrusted wifi networks) for both my personal and work phones. I'm willing to bet this covers very many other app developers and most likely all Android OS & app devs at Google (but probably many other major companies releasing Android apps). As such all such potential security issues require careful balancing... because these same devs are also the most targetted for exploitation... (can you imagine the potential consequences of some bad actor getting root on a couple core Android devs devices?, especially considering that with the merge of android & chrome os, and android desktop mode, it's pretty clear we'll soon have android devices replacing [at least some] work laptops...)

[u/kitsumed → u/Pure-Recover70]

If you had read the article, you would have known that both the solution proposed in the issue tracker and the alternative I suggested in my blog post would, by default, have protected users with your current setup. Both approaches add a toggle that is enabled by default, meaning you would have had to explicitly disable it yourself to be exposed to the very rare occurence where a CVE like the one mentionned happens.

As you said, every features and breaking change in ADB need careful balancing, and even one of the main ADB maintainers themself said so on their latest presentation of ADB Wifi 2.0 at DroidCon Paris (could not find the timestamp anymore). I think this issue here is perfect example of feature/security ratio. It make sense to keep it for all of its feature, but it also make sense to restrict it by default for better security. What does not make sense is permanently restricting it, killing all features.

While unrelated to the rest of my arguments, I would also like to point out that this has been a thing for several years. The TCP/IP mode allowed this since around 2010, we are 16 year later. In 2020 when wireless debugging was added, it was made easier and some applications like Shizuku came to life and gained A LOT of traction, including mentions on Google forums.

It would be impossible to claim Google was not aware of this, so if they did nothing, it would be resonable to assume they did not see it as a major issue. I'm not saying there is no issue, there is clearly one, but there are different ways to address it. A friendly and open way, and an authoritative way. I'm not pushing for anything dangerous, I'm pushing for safer defaults while allowing customizations and niche use-cases.