Android On-Device ADB 限制：對 Shizuku 與開發者工作流程的影響

Android On-Device ADB 限制：對 Shizuku 與開發者工作流程的影響

Google 正在考慮一項功能，旨在將 Android Debug Bridge (ADB) 限制在特定的網路介面，此舉可能會破壞 Shizuku 和 Termux 等工具所使用的「裝置內 ADB (On-Device ADB)」迴路連接 (loopback connections)。這項目前出現在 Google IssueTracker 上的功能請求提案，旨在減輕安全性漏洞，但也威脅到開發者與無障礙工具的利基生態系統。

提議的變更與安全性背景

Google 開發者正在研究一項功能，允許開發者選擇 ADB 守護行程 (ADBD) 監聽哪個網路介面。這是對安全性疑慮的直接回應，特別是在發現 CVE-2026-0073 之後，該漏洞允許繞過無線 ADB 驗證。

目前，ADBD 會在手機連接的所有網路介面上開放。提議的解決方案旨在透過限制守護行程的可用性來減少這種暴露。然而，一位核心 ADB 維護者建議了一種特定的實作方式：將 ADB 連線僅限制在無線介面 (wlan0)。

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?

對裝置內 ADB 的影響

將 ADB 限制在像 wlan0 這樣的特定介面將會破壞「裝置內 ADB」的工作流程。這指的是 ADB 用戶端直接在 Android 裝置上執行（使用像 Termux 這樣的終端機模擬器）並透過迴路位址 (127.0.0.1) 連接到本地守護行程的情況。

這種迴路連接對於多個高實用性應用程式至關重要：

  • Shizuku: 一個允許應用程式在不需要完整 root 權限的情況下執行高階系統操作的工具。
  • libadb-android: 一個用於在 Android 應用程式中實作 ADB 功能的函式庫。
  • 無障礙與實用工具: 像 ShizuCallRecorder 這樣的應用程式，依賴 Shizuku 為身障用戶提供功能。

如果 ADB 守護行程被禁止綁定到迴路介面，這些工具將失去運作能力，因為它們無法與本地 ADB 伺服器建立連接。

安全性分析：風險真的存在嗎？

批評者與開發者認為，裝置內 ADB 帶來的安全性風險被誇大了，因為 ADB 連線需要使用者的手動介入。惡意應用程式無法單獨建立 ADB 連線；它需要人類執行特定的、高權限的操作。

漏洞利用的障礙

在大多數情況下，惡意應用程式在使用者不知情的情況下無法獲得 ADB 存取權：

  1. 標準使用者: ADB 預設是停用的。啟用它需要手動進入開發者選項。
  2. 無線偵錯 (Android 11+) : 即使啟用了無線偵錯，使用者也必須使用代碼或 QR code 進行一次性的配對程序。
  3. TCP/IP 連線: 透過 TCP/IP 建立連線首先需要透過 USB 連線進行手動指令，隨後的連線嘗試會在裝置螢幕上觸發授權提示。

A malicious application could use an on-device ADB connection to perform privilege escalation. However, it cannot establish one by itself.

社群疑慮與「鎖定」論點

圍繞這項變更的討論凸顯了安全性與使用者自主權之間日益增長的緊張關係。開發者社群中的許多人認為這些限制是 Android 走向更趨向「封閉」體驗（類似 iOS）的大趨勢的一部分。

  • 控制 vs. 安全性: 一些評論者認為，此舉與安全性關係較小，更多是關於 Google 對生態系統的控制，可能會限制第三方開發者在 Google 官方管道之外創建強大工具的能力。
  • 使用者自主權: 社群提出的一個常見反向提案是實作一個持久的、由使用者控制的開關，且在重啟後依然有效。這將允許進階使用者選擇啟用迴路 ADB，同時對一般使用者保持禁用，以防止意外的漏洞利用。
  • 「側載 (Sideloading)」的關聯: 有人擔心這些限制是限制側載應用程式的次要手段，繼先前 Android 對側載權限的變更之後。

Sources