Comment by xg15

12 hours ago

> Scenario 3: A Developer Using ADB over TCP/IP

- You install a malicious application.

- You enable USB debugging, starting ADBD.

- You connect via USB ADB to enable TCP/IP, then disconnect the USB cable.

- ADBD continues running and listens on all network interfaces.

- The application initiates a connection, causing an authorization prompt to appear on the screen. If the user selects No, the connection is rejected. No silent exploitation attempts are possible.

I understand the author's rationale and think the reasons why that whole ecosystem is accessing ADB are legitimate - but I have some questions here.

The above flow is basically what apps that use Shizuku have to do as well, right? Only that in that case, the user would deliberately install the app and have the knowledge it uses ADB features and therefore would also confirm the permission prompt.

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

So it also cannot remember that a particular app was already authorized by the user and has to display the prompt again on each connection attempt?

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

This seems honestly like Shizuku itself would increase the risk of a user granting ADB access to a bad actor (i.e. a second app or external connection that is different from the app the user wanted to authorize).

Thinking of "scenario 3" if a Shizuku-enabled app is already running on the device and something else wants to connect to ADB:

- I'm assuming a malicious app was already installed (without privileges) or something tries to connect to port 5555 from outside or via proxyware.

- ADBD is already running and listening for TCP to serve the Shizuku app, so those steps can be taken for granted.

- The malicious app or connection triggers a permission prompt from ADBD. However, by that time, the user has grown used to those prompts, because the Shizuku triggers them frequently, so they are more likely to select "yes".

If ADBD has no information about who is connecting, it also can't show any meaningful information in the prompt. So it cannot really help the user distinguish prompts from the legitimate Shizuku app from malicious prompts. A user still has the timing and context to distinguish prompts, i.e. prompts that appear out of the blue when they aren't using the app are suspicious.

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

  • Ah, that makes more sense and then of course the scenario would not work that way. Thanks for clearing that up!