Android Mungkin Segera Membatasi ADB di Dalam Perangkat

 (kitsumed.github.io)
2 poin oleh GN⁺ 4 jam lalu | 2 komentar | Bagikan ke WhatsApp
  • Bukan pengumuman resmi Google, melainkan permintaan fitur IssueTracker yang masih berlangsung, tempat maintainer inti ADB menyinggung opsi membatasi koneksi lokal dan hanya melakukan binding ke wlan0 untuk mencegah penyalahgunaan
  • Jika hanya wlan0 yang diizinkan, ADB di dalam perangkat yang memakai alamat loopback 127.0.0.1, serta ADB berbasis VPN/Ethernet dan berbagai lingkungan pengembangan, mungkin tidak lagi berfungsi
  • Diskusi bermula dari CVE-2026-0073, yang sepenuhnya melewati autentikasi Wireless ADB; permintaan awalnya adalah memungkinkan pemilihan antarmuka penerima ADBD agar tidak terekspos ke semua jaringan
  • Aplikasi berbahaya pada umumnya tidak dapat memulai ADBD secara langsung atau menyelesaikan pairing Wireless ADB maupun persetujuan TCP/IP sendirian, sehingga sulit memperoleh hak ADB tanpa tindakan manual pengguna
  • Jika koneksi loopback diblokir permanen, alat berbasis Shizuku dan libadb-android akan terdampak, sehingga diperlukan pengaturan pilihan pengguna yang bisa menonaktifkan pemblokiran default bahkan setelah reboot

Bukan pengumuman resmi, melainkan diskusi awal

  • Isu ini bukan kebijakan final atau pengumuman resmi Google, melainkan berdasarkan permintaan fitur IssueTracker yang sedang berlangsung dan komentar dari maintainer inti ADB
  • Maintainer tersebut menyinggung opsi melakukan binding ADBD hanya ke antarmuka Wi-Fi wlan0, dengan mencontohkan kasus aplikasi yang memakai soket lokal ADBD untuk meningkatkan hak akses
  • Dalam diskusi publik, sebaiknya hindari protes atau hinaan semata, serta pengulangan kasus penggunaan yang sama
    • Jika ada kasus penggunaan yang unik, pengguna dapat meninggalkan masukan secara spesifik, termasuk alur kerja, tautan terkait, dan kompromi teknis
    • Jika kasus yang sama sudah terdaftar, disarankan memakai +1 dan fitur notifikasi daripada mengulang komentar
    • Jika komentar berkualitas rendah membanjir, isu dapat dikunci atau masukan berguna dan pembaruan publik bisa berkurang

Tiga cara koneksi ADB

  • ADB adalah protokol yang menyediakan akses perintah berhak tinggi bagi developer dan pengguna tingkat lanjut untuk menguji serta mengelola perangkat Android
  • Cara koneksi utamanya terbagi menjadi tiga
    • USB: cara asli yang menghubungkan komputer terpisah langsung ke perangkat dengan kabel USB
    • ADB TCP/IP: umumnya memakai port 5555, traffic dikirim dalam plaintext dan diautentikasi lewat jendela persetujuan YES/NO. Untuk mengaktifkannya diperlukan koneksi ADB yang sudah ada
    • Wireless Debugging: diperkenalkan di Android 11; komputer dipasangkan dengan kode atau QR code, lalu koneksi yang diautentikasi dan terenkripsi dibuat. Untuk mengaktifkannya tidak diperlukan koneksi ADB yang sudah ada

Ekosistem yang dibentuk oleh ADB di dalam perangkat

  • ADB biasa menghubungkan ADBD di perangkat Android dengan klien ADB di komputer pengembangan terpisah, tetapi ada juga developer yang bekerja langsung dari perangkat Android tanpa komputer
  • ADB di dalam perangkat (On-Device ADB) bukan istilah resmi, dan merujuk pada cara menjalankan klien ADB di emulator terminal seperti Termux untuk terhubung ke ADBD di perangkat yang sama
    • Menggunakan ADB TCP/IP atau Wireless Debugging
    • Karena klien dan server berada di perangkat yang sama, koneksi melewati alamat loopback 127.0.0.1
  • Cara ini menjadi fondasi bagi proyek open source untuk developer dan pengguna tingkat lanjut seperti libadb-android dan Shizuku
  • ShizuCallRecorder adalah aplikasi berbasis Shizuku yang dibuat untuk mengurangi kesulitan sehari-hari akibat disabilitas
    • Seorang pengguna memakai aplikasi ini untuk menyimpan voicemail dari anggota keluarga yang telah meninggal
    • Perekaman panggilan Android banyak diminta pengguna dan sempat didorong sebagai fitur resmi di Android 11 sebelum dibatalkan; saat ini juga ada aplikasi workaround yang bersifat tertutup atau berpotensi melanggar privasi
    • Sebagian OEM memaksakan pengumuman suara perekaman panggilan bahkan di wilayah yang tidak mewajibkannya secara hukum

Permintaan pemilihan antarmuka dan pembatasan wlan0

  • Tujuan awal permintaan fitur baru ini adalah memungkinkan developer memilih antarmuka jaringan tempat ADBD menerima koneksi
  • Latar belakangnya adalah CVE-2026-0073, yang memungkinkan prosedur autentikasi Wireless ADB dilewati sepenuhnya
  • Saat ini ADBD dapat diakses dari semua jaringan yang terhubung ke ponsel, sehingga fitur pemilihan antarmuka sendiri dapat mengurangi area eksposur
  • Namun, jika hanya wlan0 yang diizinkan, konfigurasi berikut dapat rusak
    • ADB di dalam perangkat yang memakai loopback
    • ADB melalui VPN
    • ADB melalui Ethernet
    • Lingkungan pengembangan khusus lainnya
  • Developer Android juga pernah menggunakan ADB di dalam perangkat saat tidak dapat mengakses komputer

Batasan yang harus dilampaui aplikasi berbahaya

  • ADB di dalam perangkat memang dapat digunakan untuk peningkatan hak akses, tetapi aplikasi berbahaya biasa tidak dapat membentuk koneksi sendiri

  • Pengguna Android umum

    • Jika ADB dinonaktifkan, ADBD tidak berjalan
    • Aplikasi berbahaya juga tidak memiliki izin WRITE_SECURE_SETTINGS yang harus diberikan manual lewat ADB, sehingga sulit mencoba serangan ADB

  • Developer yang memakai Wireless ADB di Android 11 ke atas

    • Pengguna harus mengaktifkan USB debugging dan Wireless ADB sendiri agar ADBD menerima koneksi di antarmuka jaringan
    • Agar aplikasi dapat terhubung, pengguna harus mengambil dan memberikan kode pairing sekali pakai dari layar pengaturan, sehingga aplikasi saja tidak bisa membuat koneksi

  • Developer yang memakai ADB TCP/IP

    • Pengguna harus menyalakan USB debugging, mengaktifkan TCP/IP melalui USB ADB, lalu mencabut kabel
    • Jika aplikasi mulai terhubung, jendela persetujuan muncul di layar, dan koneksi ditolak jika pengguna memilih No
    • Dalam kondisi autentikasi normal, aplikasi tidak dapat terhubung diam-diam tanpa sepengetahuan pengguna untuk menyerang

Risiko kerentanan dan cakupan pemblokiran

  • Dalam situasi normal, aplikasi berbahaya tidak dapat memulai ADBD secara langsung, sehingga kemungkinan koneksi hanya muncul saat developer sedang memakai ADB di perangkat
  • Jika ada kerentanan yang melewati autentikasi seperti CVE-2026-0073, hal itu dapat dieksploitasi di lingkungan Wireless ADB dan TCP/IP
    • Meski begitu, pengguna tetap harus lebih dulu mengaktifkan USB debugging secara manual
    • Untuk metode TCP/IP, pengguna juga harus menyalakan ADB TCP/IP sendiri
  • Tindakan memblokir koneksi loopback secara default perlu dibedakan dari pemblokiran permanen yang tidak dapat dinonaktifkan pengguna
  • Penetapan sebagai device administrator atau izin aksesibilitas juga dapat diberikan kepada aplikasi berbahaya melalui tindakan pengguna, tetapi kemungkinan itu saja tidak membuat fiturnya dihapus sepenuhnya

Kompromi yang menyisakan pilihan bagi pengguna

  • Pemblokiran loopback harus menjadi pengaturan persisten yang dapat dinonaktifkan secara eksplisit oleh pengguna
    • Harus tetap bertahan setelah reboot agar alat seperti Shizuku dapat digunakan secara praktis
    • Jika memungkinkan, aplikasi pihak ketiga tidak boleh dapat membaca status pengaturan tersebut, agar pengguna tidak perlu berulang kali mengubahnya untuk menghindari deteksi oleh aplikasi bank atau game
    • Jika izin WRITE_SECURE_SETTINGS diberikan manual kepada aplikasi, sebagian batasan dapat dilewati
  • Struktur yang tepat adalah pengguna dapat mematikan fitur keamanan dan mengizinkan debugging di dalam perangkat, sekaligus menerima risiko terekspos pada kerentanan di masa depan
  • Jika ADB di dalam perangkat diblokir permanen, ekosistem open source niche berikut akan terdampak

Bacaan terkait

2 komentar

 
unsure4000 1 jam lalu

eww...
 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Secara umum saya setuju dengan peningkatan keamanan, tetapi dalam kasus ini manfaat nyatanya tampak sangat kecil. Agar serangan ini bisa terjadi, pengguna harus mengaktifkan pengaturan developer dan ADB jarak jauh sekaligus, jadi bagi 99,9% orang ini bukan jalur serangan yang realistis, dan 0,1% sisanya biasanya tahu apa yang mereka lakukan
    Perubahan yang membatasi akses ke antarmuka atau IP tertentu itu bagus, tetapi cukup beri developer kemampuan untuk membatasinya ke localhost. Kesan kuatnya adalah mereka ingin memblokir Shizuku, Canta, dan sejenisnya dengan menyamarkannya sebagai korban sampingan

    • Sekarang keamanan nyaris menjadi bencana dalam perangkat lunak. Setiap situs sepele meminta autentikasi dua faktor, membuat kita logout setiap beberapa jam, dan meski sudah mengetik disable sandbox untuk menjalankan agen dalam mode tanpa batas, itu tetap tidak berfungsi di perangkat mobile
      Di Firefox, ekstensi yang tidak ditandatangani sama sekali tidak bisa dipasang sehingga perlu Developer Edition; situs-situs memaksa passkey; bahkan satu bucket S3 pun ditempeli puluhan lapis kontrol akses, identitas layanan, IAM, dan OAuth. OAuth yang tidak berfungsi di perangkat headless, bank yang meminta aplikasi khusus alih-alih TOTP, pemblokiran VPN, pengawasan nama asli dengan dalih perlindungan anak, serta upaya melarang model open-weight dengan alasan informasi akan bocor ke Tiongkok juga terus berlanjut
      Keamanan telah menjadi nilai absolut yang selalu didahulukan atas kenyamanan, kegunaan, privasi, kemampuan untuk dimodifikasi, dan keterbukaan, dan industri keamanan TI seharusnya malu karenanya
    • Pengaturan developer dan ADB jarak jauh saja pun belum cukup. Build Android biasa akan meminta pengguna menyetujui kunci klien lagi saat koneksi dibuat
      Perubahan ini tampaknya bukan demi keamanan pengguna, melainkan untuk melindungi kepentingan perusahaan
    • Setelah iPhone, banyak perubahan yang dibungkus sebagai fitur keamanan sebenarnya adalah penghapusan kemampuan perangkat
      Pada awalnya mereka menyuruh orang memakai Safari saja tanpa App Store, dan menurut saya akarnya adalah paranoia khas Steve Jobs, yang bahkan saat menjalani pengobatan kanker enggan membiarkan perangkat medis yang desainnya tidak indah menyentuh tubuhnya. Sikap yang ingin mencegah hal “kotor” menyentuh perangkat yang “sempurna” itu kemudian dibenarkan setelah kematiannya dengan bahasa keamanan
      Saat itu alasannya adalah menghindari situasi seperti Windows 98 yang penuh malware, tetapi sistem operasi modern sudah jauh melampaui tingkat keamanan Windows yang lemah pada masa itu
    • Saya adalah developer yang pernah merilis aplikasi Android, tetapi saat layar perangkat rusak, toggle ADB jarak jauh yang merepotkan itu ternyata mati sehingga saya tidak bisa mengakses perangkat. Kasus pengaturan developer dan ADB jarak jauh aktif bersamaan sangat jarang di lingkungan nyata sampai bisa diabaikan sebagai jalur serangan
    • Pernyataan bahwa “pelaku jahat tidak bisa mendapatkan koneksi ADB dalam kondisi normal” bergantung pada bagaimana pelaku jahat didefinisikan
      Tujuan memblokir alat privasi tanpa root berbasis Shizuku adalah untuk keamanan pemerintah, bukan pemilik perangkat. Aplikasi trusted execution environment seperti EU Digital Identity Wallet dan fitur-fitur yang kelak akan diminta dengan dalih perlindungan anak sangat bergantung pada asumsi bahwa pengguna tidak bisa mengutak-atik perangkat atau memasang perangkat lunak yang tidak disetujui. Kita semua tahu bagaimana nasib Intel SGX

  • Pembatasan ADB adalah langkah berikutnya yang wajar. Kalaupun proposal ini tidak lolos apa adanya, Google sudah membuat pekerjaan komputasi pribadi yang normal pun bergantung pada antarmuka developer di dalam perangkat atau melalui USB/nirkabel
    Suatu saat besar kemungkinan kita harus menyerahkan identitas dan membayar biaya tahunan, atau menghadapi pembatasan serius untuk menggunakan Android secara bermakna. Google tidak ingin orang mengembangkan aplikasi Android di luar jalur distribusi yang dikendalikan, dan ketika mereka tidak mundur dari perubahan yang melarang sideloading yang normal dan sah, pada dasarnya kita sudah kalah
    Peringatan perekaman panggilan juga tanggung jawab Google. Saat produsen mengadopsi dialer Google alih-alih dialer buatan sendiri yang lebih baik, itu diterapkan seragam bahkan di wilayah yang tidak memiliki kewajiban hukum. Ini terutama merepotkan pada SoC MediaTek yang tidak mendukung perekaman lewat aplikasi pihak ketiga yang stabil di tingkat hardware
    Pada akhirnya ini bukti bahwa kita tidak memiliki perangkat “milik kita” sendiri, dan beberapa tahun lagi mungkin Gemini akan mendengarkan dan merangkum panggilan melalui jalur pengawasan yang disetujui

    • Kasus saya berbeda. Tulisan ini dikirim dari smartphone GNU/Linux Librem 5
    • Jika Anda bisa memasang sistem operasi sendiri, berarti Anda memiliki perangkat itu. Google secara konsisten mengizinkan hal ini, jadi kemarahan seharusnya diarahkan ke produsen lain yang memblokirnya

  • Saya penasaran apakah sarana alternatif untuk penggunaan yang sah juga disediakan. Jika sebuah fitur dihapus tanpa memberi alternatif, developer akan terdorong memakai workaround yang lebih rentan atau kadang melanggar aturan

  • Reaksi kali ini tampaknya merupakan reaksi berlebihan besar yang berawal dari salah paham. Saya memasang build baru proyek Android yang sedang dikembangkan melalui ADB jarak jauh dan mengambil log, dan saat ini tersambung lewat Tailscale VPN
    Namun dengan cara sekarang, di setiap Wi-Fi publik yang saya sambungkan, bahkan kerentanan praautentikasi bisa terekspos. Jika bisa dibatasi hanya ke antarmuka Tailscale, itu justru peningkatan
    Inti proposalnya adalah menentukan antarmuka yang akan di-bind saat mengatur ADB jarak jauh, bukan semua antarmuka. Tidak ada keterangan bahwa localhost akan ditolak, dan proposal singkat untuk hanya bind ke wlan0 jelas keliru karena kurang tepercaya dibanding VPN, serta kemungkinan bukan arah implementasi sebenarnya

  • Meski developer Google mengunci issue karena thread dibanjiri dan mengabaikan feedback, tidak ada yang akan berubah dari kondisi sekarang. Jika kritik itu sendiri terasa mengganggu, feedback yang bernilai pun bisa saja dikunci, jadi silakan bebas menyatakan dukungan

    • Kritik kebijakan harus dibedakan dari serbuan massa ala Reddit
    • Premis tulisan bahwa developer Google sekadar melewatkan atau salah memahami use case penting dan akan mempertimbangkan ulang jika diberi tahu, terus terang terasa menghina
    • Begitu tulisan seperti ini muncul di HN atau Reddit, peluang untuk mengubah pikiran seseorang lenyap dan issue GitHub kemungkinan besar segera dibanjiri
      Google memang kadang menerima feedback dari developer aplikasi, tetapi wajar jika mereka lebih mengutamakan penilaian tim internal daripada developer open-source yang bergantung pada trik semacam ini
      ADB daemon jelas tidak dirancang agar aplikasi bisa membuka sesi ADB ke alamat loopback demi memungkinkan perekaman panggilan. https://xkcd.com/1172/ kembali teringat
      Itu bukan berarti developer salah karena tidak menyukai perubahan ini. Google juga sudah menambahkan perekaman panggilan ke dialer, jadi mereka mendukung fitur tersebut, tetapi bukan berarti tim ADB tidak boleh melakukan penguatan keamanan

  • Saat Google pertama kali mengumumkan pembatasan sideloading, orang berkata, “toh masih ada ADB,” dan mereka yang menentangnya mendapat kritik keras.
    Sekarang kita bahkan harus menunggu cara memutar untuk mengaktifkan ADB, dan Android sudah sejak lama tidak lebih terbuka daripada iOS. Arah ini akan terus berlanjut.
    Ini adalah masalah nonteknis berupa pola pikir Google, jadi tidak bisa diselesaikan dengan solusi teknis.

    • Begitu atestasi jarak jauh berbasis perangkat keras diperkenalkan, Android sebenarnya sudah tidak punya harapan.
      Meski bisa memasang perangkat lunak sendiri, perangkat akan diperlakukan sebagai “dimodifikasi”. Jika gagal atestasi, perangkat tidak akan dipercaya dan penggunanya menjadi warga kelas dua yang tersingkir dari hampir semua bidang masyarakat digital, seperti komunikasi, perbankan, streaming, dan gim.
      Itulah masa depan Android, dan GrapheneOS adalah harapan terakhir karena beberapa perusahaan secara ajaib mulai memercayai kunci atestasi GrapheneOS. Jika harapan itu pun hilang, lebih baik membeli iPhone saja.
    • Rantai yang mengendalikan pola pikir semacam ini menjulur jauh melampaui manajemen dan dewan direksi Google. Ini mengingatkan pada OBEY dalam karya klasik Carpenter.

  • Ini memang sudah pasti akan terjadi. Berikutnya, orang mungkin masih akan terkejut kalau pembatasan sideloading 24 jam berubah menjadi tanpa batas waktu.

    • Kemungkinan besar perubahan menjadi pembatasan tanpa batas waktu akan bergantung pada apakah ada alternatif yang realistis untuk berpindah sebelum itu.
      Tidak perlu menguasai seluruh pasar; cukup membuat Google ragu atau membuatnya sulit dijalankan secara hukum. Mirip dengan peran ideal Firefox terhadap Chrome.

  • Android yang terkunci sejauh ini adalah sinyal peringatan serius. Mereka perlahan-lahan menghapus satu per satu hal yang dulu membuat Android bagus.

  • Saya khawatir hal yang sama akan segera terjadi pada situs web. Bisa saja untuk membuat situs dapat dibuka di perangkat Apple, kita harus membayar biaya bulanan kepada Apple, dan di perangkat Android kepada Google.

    • reCAPTCHA baru yang mensyaratkan atestasi jarak jauh sudah mengarah ke sana.
      https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
      Memang belum ada biaya, tetapi Google jadi bisa menentukan perangkat mana yang diizinkan mengakses banyak situs web.
    • Web bisa terbelah dua: web baru tempat situs-situs besar papan atas membayar biaya, dan web lama yang hanya bisa diakses jika memiliki PC pribadi dengan peramban tanpa pembatasan terpasang.
      Konten dari web lama kemungkinan besar akan diambil secara masif oleh perusahaan AI lalu direproduksi kepada publik melalui web baru.
    • Pada layanan streaming video seperti Netflix, hal serupa sudah terjadi. Kita memang tidak perlu membayar langsung, tetapi tidak bisa menggunakan peramban open-source.

  • Kita membutuhkan Linux untuk smartphone. Untuk perbankan, jika bisa dilakukan lewat peramban maka aplikasi tidak diperlukan, tetapi perangkat komunikasi nirkabel dan aplikasi utama seperti Sonos dan Spotify harus bisa berfungsi.

    • Banyak bank di Inggris kini tidak lagi menyediakan portal web maupun cabang fisik.
      Diperlukan undang-undang yang mewajibkan lingkungan web yang berfungsi normal untuk layanan esensial seperti perbankan dan utilitas publik. Jika tidak, duopoli yang ada sekarang akan makin mengakar.
      Saya sendiri juga harus lebih aktif mendukung penyedia yang menawarkan layanan web.
    • Menyarankan Android, LineageOS, atau GrapheneOS tidak tepat, dan Sailfish juga sebaiknya dilewati karena memiliki banyak komponen proprietary. Pilihan terbaik adalah postmarketOS, dan Mobian serta lainnya juga layak dipertimbangkan, sedangkan Ubuntu Touch dan UBports mengecewakan.
      Periksa perangkat yang kompatibel di wiki postmarketOS untuk melihat apakah perangkat yang sudah dimiliki didukung, dan jika memungkinkan berkontribusilah untuk meningkatkan dukungannya. Jika tidak, perangkat bekas dengan status dukungan yang baik bisa dicari di eBay.
      Librem 5 dan PinePhone memiliki dukungan yang cukup baik, tetapi perangkat Android lama seperti OnePlus 6T mungkin menawarkan performa lebih baik untuk harganya. Sebelum membeli, pastikan fungsi-fungsi utamanya berjalan.
      Aplikasi Android populer bisa dijalankan dengan Waydroid.
    • Kita harus menuntut kesetaraan fitur antara situs web bank dan aplikasi native. Bank saya hanya mendukung setoran cek jarak jauh lewat aplikasi, dan aplikasinya tidak berjalan di perangkat lama sehingga saya harus memakai PayPal.
    • Semua smartphone perlu memiliki bootloader yang bisa dibuka kuncinya. Dengan begitu, lebih banyak sistem operasi bisa muncul.
    • Bank-bank sekarang memaksa penggunaan aplikasi dengan alasan “keamanan”, dan hampir mustahil mengurus apa pun tanpa aplikasi.
      Alternatifnya, autentikasi SMS, juga tidak aman sehingga mulai dihapus; dari sisi keamanan itu arah yang benar, tetapi pilihan lain yang dapat digunakan masih kurang.