- Trong một yêu cầu tính năng trên IssueTracker đang được thảo luận, không phải công bố chính thức từ Google, người bảo trì cốt lõi của ADB đã đề cập phương án hạn chế kết nối cục bộ để ngăn lạm dụng và chỉ bind vào
wlan0 - Nếu chỉ cho phép
wlan0, thì không chỉ ADB trên thiết bị dùng địa chỉ loopback127.0.0.1, mà cả ADB qua VPN·Ethernet và nhiều môi trường phát triển khác cũng có thể ngừng hoạt động - Cuộc thảo luận bắt đầu từ CVE-2026-0073, lỗ hổng cho phép bỏ qua hoàn toàn xác thực Wireless ADB; yêu cầu ban đầu là cho phép chọn giao diện nhận kết nối của ADBD để không bị phơi ra trên mọi mạng
- Ứng dụng độc hại thông thường không thể tự khởi động ADBD hay tự hoàn tất ghép đôi Wireless ADB hoặc phê duyệt TCP/IP, nên rất khó giành được quyền ADB nếu không có thao tác thủ công từ người dùng
- Nếu chặn vĩnh viễn kết nối loopback thì các công cụ dựa trên Shizuku và libadb-android sẽ bị ảnh hưởng, vì vậy cần có tùy chọn do người dùng chọn để tắt chặn mặc định ngay cả sau khi khởi động lại
Thảo luận ban đầu, không phải công bố chính thức
- Vấn đề lần này không phải chính sách đã được chốt hay công bố chính thức từ Google, mà dựa trên yêu cầu tính năng trên IssueTracker đang được thảo luận cùng các bình luận từ người bảo trì cốt lõi của ADB
- Người phụ trách nêu ví dụ về trường hợp ứng dụng dùng socket cục bộ của ADBD để leo thang đặc quyền, và đề cập phương án bind ADBD chỉ vào
wlan0, tức giao diện Wi‑Fi - Trong thảo luận công khai, nên tránh phản đối đơn thuần, công kích, hoặc lặp lại cùng một trường hợp sử dụng
- Nếu có trường hợp sử dụng riêng, có thể để lại ý kiến cụ thể kèm quy trình làm việc, liên kết liên quan và phương án dung hòa về mặt kỹ thuật
- Nếu cùng trường hợp đã được nêu rồi, nên dùng +1 và tính năng thông báo thay vì lặp lại bình luận
- Nếu quá nhiều bình luận chất lượng thấp đổ vào, issue có thể bị khóa hoặc lượng phản hồi hữu ích và cập nhật công khai có thể giảm đi
Ba cách kết nối của ADB
- ADB là giao thức cung cấp quyền truy cập lệnh mức đặc quyền cao cho nhà phát triển và người dùng nâng cao để thử nghiệm, quản lý thiết bị Android
- Có ba cách kết nối chính
- USB: cách nguyên bản, kết nối trực tiếp thiết bị bằng cáp USB từ một máy tính riêng
- ADB TCP/IP: thường dùng cổng
5555, truyền tải lưu lượng ở dạng văn bản thuần và xác thực bằng cửa sổ phê duyệt YES/NO. Chỉ có thể bật sau khi đã có kết nối ADB sẵn - Wireless Debugging: được giới thiệu từ Android 11, ghép đôi máy tính bằng mã hoặc QR code rồi thiết lập kết nối đã xác thực và mã hóa. Không cần kết nối ADB có sẵn để kích hoạt
Hệ sinh thái do ADB trên thiết bị tạo ra
- ADB thông thường kết nối ADBD trên thiết bị Android với ADB client trên một máy phát triển riêng, nhưng cũng có những nhà phát triển làm việc trực tiếp trên chính thiết bị Android mà không cần máy tính
- ADB trên thiết bị (On-Device ADB) không phải thuật ngữ chính thức, mà chỉ cách chạy ADB client trong trình giả lập terminal như Termux để kết nối tới ADBD của chính thiết bị đó
- Dùng ADB TCP/IP hoặc Wireless Debugging
- Vì client và server nằm trên cùng một thiết bị, kết nối đi qua địa chỉ loopback
127.0.0.1
- Cách này là nền tảng cho các dự án mã nguồn mở dành cho nhà phát triển và người dùng nâng cao như libadb-android, Shizuku
- ShizuCallRecorder là ứng dụng dựa trên Shizuku được tạo ra để giảm khó khăn thường nhật do khuyết tật gây ra
- Một người dùng đã dùng ứng dụng này để lưu giữ hộp thư thoại của người thân đã qua đời
- Tính năng ghi âm cuộc gọi trên Android từng có nhiều yêu cầu từ người dùng, từng được thúc đẩy như tính năng chính thức ở Android 11 rồi bị hủy, và hiện cũng tồn tại các ứng dụng lách luật dạng đóng hoặc có thể xâm phạm quyền riêng tư
- Một số OEM buộc phát thông báo ghi âm cuộc gọi ngay cả ở những khu vực pháp lý không yêu cầu
Yêu cầu chọn giao diện và giới hạn wlan0
- Mục đích ban đầu của yêu cầu tính năng mới là cho phép nhà phát triển chọn giao diện mạng mà ADBD sẽ lắng nghe
- Bối cảnh là CVE-2026-0073, lỗ hổng có thể bỏ qua hoàn toàn quy trình xác thực Wireless ADB
- Hiện tại ADBD có thể bị truy cập từ mọi mạng mà điện thoại đang kết nối, nên riêng tính năng chọn giao diện đã có thể giúp giảm phạm vi bị phơi ra
- Tuy nhiên, nếu chỉ cho phép
wlan0thì các cấu hình sau có thể bị phá vỡ- ADB trên thiết bị dùng loopback
- ADB qua VPN
- ADB qua Ethernet
- Các môi trường phát triển đặc thù khác
- Ngay cả nhà phát triển Android cũng từng dùng ADB trên thiết bị khi không thể truy cập máy tính
Những ràng buộc mà ứng dụng độc hại phải vượt qua
- ADB trên thiết bị có thể bị dùng để leo thang đặc quyền, nhưng ứng dụng độc hại thông thường không thể tự thiết lập kết nối
-
Người dùng Android thông thường
- Nếu ADB đang tắt thì ADBD sẽ không chạy
- Ứng dụng độc hại cũng không có quyền
WRITE_SECURE_SETTINGS, vốn phải được cấp thủ công qua ADB, nên khó thực hiện tấn công qua ADB
-
Nhà phát triển dùng Wireless ADB trên Android 11 trở lên
- Người dùng phải tự bật USB debugging và Wireless ADB thì ADBD mới lắng nghe trên giao diện mạng
- Để ứng dụng kết nối, người dùng phải lấy và cung cấp mã ghép đôi dùng một lần từ màn hình cài đặt, nên chỉ ứng dụng một mình thì không thể kết nối
-
Nhà phát triển dùng ADB TCP/IP
- Người dùng phải bật USB debugging, bật TCP/IP qua USB ADB rồi mới rút cáp ra
- Khi ứng dụng bắt đầu kết nối, cửa sổ phê duyệt sẽ hiện lên; nếu người dùng chọn No thì sẽ bị từ chối
- Trong trạng thái xác thực bình thường, ứng dụng không thể âm thầm kết nối để tấn công mà người dùng không biết
Rủi ro lỗ hổng và phạm vi chặn
- Trong tình huống bình thường, ứng dụng độc hại không thể trực tiếp khởi động ADBD, nên chỉ khi nhà phát triển đang dùng ADB trên thiết bị thì mới có khả năng kết nối
- Nếu có lỗ hổng bỏ qua xác thực như CVE-2026-0073, việc khai thác có thể xảy ra trong môi trường Wireless ADB và TCP/IP
- Dù vậy, trước hết người dùng vẫn phải tự bật USB debugging
- Với cách TCP/IP, người dùng còn phải tự bật cả ADB TCP/IP
- Cần phân biệt giữa việc mặc định chặn kết nối loopback và việc chặn vĩnh viễn không cho người dùng tắt đi
- Việc chỉ định ứng dụng quản trị thiết bị hay cấp quyền trợ năng cũng có thể bị người dùng cấp cho ứng dụng độc hại qua thao tác thủ công, nhưng không vì khả năng đó mà xóa bỏ luôn tính năng
Phương án dung hòa vẫn giữ quyền lựa chọn cho người dùng
- Việc chặn loopback nên là thiết lập duy trì mà người dùng có thể chủ động tắt
- Nó phải được giữ nguyên sau khi khởi động lại thì các công cụ như Shizuku mới dùng thực tế được
- Nếu có thể, ứng dụng bên thứ ba không nên đọc được trạng thái thiết lập này để tránh phải lặp đi lặp lại việc chỉnh cài đặt chỉ vì né phát hiện từ ứng dụng ngân hàng hoặc game
- Nếu cấp thủ công
WRITE_SECURE_SETTINGScho ứng dụng thì có thể vượt qua một số ràng buộc
- Cách tiếp cận phù hợp là cho phép người dùng tắt tính năng bảo mật và cho phép gỡ lỗi trên thiết bị, đồng thời chấp nhận rủi ro có thể bị phơi ra trước các lỗ hổng trong tương lai
- Nếu chặn vĩnh viễn ADB trên thiết bị, hệ sinh thái mã nguồn mở ngách sau đây sẽ bị ảnh hưởng
2 bình luận
Eo...
Ý kiến trên Hacker News
Nhìn chung tôi ủng hộ cải thiện bảo mật, nhưng trong trường hợp này hầu như không thấy lợi ích thực tế. Để kiểu tấn công này xảy ra, người dùng phải bật cả cài đặt nhà phát triển lẫn ADB từ xa, nên với 99,9% người dùng đây không phải đường tấn công thực tế, còn 0,1% còn lại thì thường biết mình đang làm gì
Việc thay đổi để giới hạn truy cập theo giao diện cụ thể hoặc IP là tốt, nhưng chỉ cần cho phép nhà phát triển giới hạn về localhost là được. Cảm giác rất giống đang muốn chặn Shizuku và Canta bằng cách ngụy trang thành thiệt hại phụ
disable sandboxđể chạy agent ở chế độ không giới hạn thì trên di động vẫn không hoạt độngTrên Firefox thì hoàn toàn không thể cài tiện ích mở rộng chưa ký nên phải dùng Developer Edition, các trang web ép dùng passkey, và chỉ một bucket S3 cũng bị phủ hàng chục lớp kiểm soát truy cập, danh tính dịch vụ, IAM và OAuth. OAuth không chạy trên thiết bị headless, ngân hàng bắt dùng ứng dụng riêng thay vì TOTP, chặn VPN, giám sát định danh thật nhân danh bảo vệ trẻ em, và cả xu hướng muốn cấm các mô hình trọng số mở vì sợ dữ liệu chảy sang Trung Quốc
Bảo mật đã trở thành giá trị tuyệt đối luôn đứng trên sự tiện lợi, tính khả dụng, quyền riêng tư, khả năng tùy biến và tính mở, và ngành bảo mật CNTT nên cảm thấy xấu hổ vì điều đó
Thay đổi lần này có vẻ không phải để bảo vệ an toàn cho người dùng mà là để bảo vệ lợi ích của doanh nghiệp
Ban đầu họ bảo cứ dùng Safari mà không cần app store, và tôi cho rằng gốc rễ là kiểu ám ảnh đặc trưng của Steve Jobs: ngay cả khi đang điều trị ung thư, ông cũng không thích các thiết bị y tế xấu xí chạm vào cơ thể mình. Đó là thái độ muốn ngăn những thứ “bẩn thỉu” chạm vào một thiết bị “hoàn hảo”, rồi sau này được hợp thức hóa bằng ngôn ngữ bảo mật
Khi đó người ta nói phải tránh tình trạng kiểu Windows 98 đầy malware, nhưng hệ điều hành hiện đại đã vượt xa mức độ bảo mật yếu kém của Windows thời đó
Mục tiêu của việc chặn các công cụ quyền riêng tư không cần root dựa trên Shizuku không phải là an ninh của chủ sở hữu mà là an ninh của chính phủ. Các ứng dụng môi trường thực thi đáng tin cậy như EU Digital Identity Wallet, cùng những tính năng sau này sẽ được yêu cầu nhân danh bảo vệ trẻ em, phụ thuộc rất nhiều vào giả định rằng người dùng không thể can thiệp thiết bị hay cài phần mềm không được phê duyệt. Ai cũng biết Intel SGX đang đi về đâu
Hạn chế ADB là bước tiếp theo hiển nhiên. Dù đề xuất này không được thông qua nguyên trạng, Google đã khiến ngay cả những tác vụ máy tính cá nhân bình thường cũng phải phụ thuộc vào giao diện nhà phát triển trên thiết bị hoặc qua USB/không dây
Rồi sẽ đến lúc khả năng cao là bạn phải giao nộp danh tính và trả phí hằng năm, hoặc bị hạn chế nghiêm trọng trong việc sử dụng Android theo cách có ý nghĩa. Google không muốn người ta phát triển ứng dụng Android ngoài kênh phân phối được kiểm soát, và coi như đã thua từ lúc họ không lùi bước trước những thay đổi cấm sideloading hợp pháp và bình thường
Cảnh báo ghi âm cuộc gọi cũng là trách nhiệm của Google. Khi các hãng dùng Google Dialer thay cho trình quay số riêng vốn tốt hơn của họ, nó bị áp dụng đồng loạt cả ở những nơi không có nghĩa vụ pháp lý. Điều này đặc biệt phiền trên các SoC MediaTek vốn không hỗ trợ ghi âm ổn định qua ứng dụng bên thứ ba ở mức phần cứng
Rốt cuộc đây là bằng chứng rằng bạn không thực sự sở hữu thiết bị “của mình”, và vài năm nữa có khi Gemini sẽ nghe cuộc gọi rồi tóm tắt cho bạn qua một kênh giám sát được phê duyệt
Tôi muốn biết liệu có giải pháp thay thế nào đi kèm cho các mục đích sử dụng chính đáng hay không. Nếu bỏ tính năng mà không đưa phương án thay thế, các nhà phát triển sẽ bị đẩy sang những cách vòng vo kém an toàn hơn, đôi khi còn vi phạm quy tắc
Phản ứng lần này có vẻ là một sự đáp trả thái quá rất lớn bắt nguồn từ hiểu lầm. Tôi dùng ADB từ xa để cài bản build mới cho dự án Android đang phát triển và lấy log, hiện kết nối qua Tailscale VPN
Nhưng cách hiện tại có thể khiến nó lộ ra cả với lỗ hổng trước xác thực trên mọi Wi‑Fi công cộng mà tôi kết nối. Nếu có thể giới hạn chỉ trên giao diện Tailscale thì ngược lại còn là cải thiện
Cốt lõi của đề xuất là khi cấu hình ADB từ xa, phải chỉ định giao diện sẽ bind thay vì mọi giao diện. Không có nội dung nào nói localhost sẽ bị từ chối, và đề xuất ngắn gọn bảo chỉ bind vào
wlan0rõ ràng là sai vì kém tin cậy hơn VPN, nên chắc cũng không phải hướng triển khai thực tếDù các nhà phát triển Google có khóa issue vì bị spam cả luồng và phớt lờ phản hồi, thì cũng chẳng khác gì hiện tại. Nếu chính sự chỉ trích làm họ khó chịu thì họ cũng có thể khóa luôn cả phản hồi có giá trị, nên cứ tự do bày tỏ sự ủng hộ
Google đôi khi có lắng nghe phản hồi từ nhà phát triển ứng dụng, nhưng hiển nhiên họ sẽ coi trọng đánh giá của đội nội bộ hơn là các nhà phát triển mã nguồn mở đang dựa vào những cách lách luật như thế này
Rõ ràng ADB daemon không được thiết kế để ứng dụng mở phiên ADB tới địa chỉ loopback nhằm cho phép ghi âm cuộc gọi. https://xkcd.com/1172/ lại hiện lên trong đầu
Điều đó không có nghĩa các nhà phát triển ghét thay đổi là sai. Google cũng đã thêm ghi âm cuộc gọi vào dialer nên bản thân tính năng đó vẫn đáng ủng hộ, nhưng không vì thế mà đội ADB không nên tăng cường bảo mật
Khi Google lần đầu công bố hạn chế sideloading, đã có người nói “vẫn còn ADB”, và những người phản đối điều đó đã bị chỉ trích dữ dội
Giờ đây thậm chí còn phải chờ cả các cách lách để kích hoạt ADB, và từ lâu Android đã không còn cởi mở hơn iOS. Xu hướng này sẽ tiếp diễn
Đây là vấn đề phi kỹ thuật trong cách suy nghĩ của Google, nên không thể giải quyết bằng biện pháp kỹ thuật
Dù có thể cài phần mềm của riêng mình, thiết bị vẫn bị xem là đã “bị chỉnh sửa”. Nếu không vượt qua chứng thực, nó sẽ không được tin cậy và bị loại khỏi gần như mọi lĩnh vực của xã hội số như liên lạc, ngân hàng, streaming, game, v.v., trở thành công dân hạng hai
Đó là tương lai của Android, và vì một vài công ty đã kỳ diệu bắt đầu tin cậy khóa chứng thực của GrapheneOS, nên GrapheneOS là hy vọng cuối cùng. Nếu ngay cả hy vọng đó cũng biến mất, thà mua iPhone còn hơn
Đây vốn là điều tất yếu sẽ xảy ra. Có lẽ tới khi giới hạn sideloading 24 giờ tiếp theo bị đổi thành vô thời hạn thì mọi người vẫn sẽ ngạc nhiên
Không cần phải chiếm toàn bộ thị trường; chỉ cần đủ để khiến Google phải do dự hoặc khó triển khai về mặt pháp lý là đủ. Vai trò lý tưởng của Firefox đối với Chrome cũng tương tự như vậy
Việc Android bị khóa chặt đến mức này là một tín hiệu cảnh báo nghiêm trọng. Họ đang chậm rãi gỡ bỏ từng yếu tố từng làm Android trở nên hấp dẫn
Tôi lo rằng điều tương tự rồi cũng sẽ xảy ra với các website. Có thể sẽ thành kiểu muốn mở trang trên thiết bị Apple thì phải trả phí hàng tháng cho Apple, còn trên thiết bị Android thì trả cho Google
https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
Dù chưa có thu phí, Google đã có thể quyết định thiết bị nào được phép truy cập vào phần lớn website
Cũng rất có thể nội dung của web cũ sẽ bị các công ty AI cào ở quy mô lớn rồi tái tạo cho công chúng thông qua web mới
Cần có Linux cho smartphone. Nếu có thể làm ngân hàng qua trình duyệt thì không cần app, nhưng các thiết bị liên lạc không dây và những app quan trọng như Sonos, Spotify phải hoạt động được
Cần có luật bắt buộc môi trường web hoạt động bình thường cho các dịch vụ thiết yếu như ngân hàng và điện nước. Nếu không, thế song mã hiện nay sẽ càng bị cố định hơn
Bản thân tôi cũng nên chủ động ủng hộ hơn bằng cách chọn những nhà cung cấp có dịch vụ web
Hãy kiểm tra trên wiki của postmarketOS xem thiết bị bạn đang có có được hỗ trợ không, và nếu có thể thì đóng góp để cải thiện hỗ trợ. Nếu không, có thể tìm thiết bị cũ có tình trạng hỗ trợ tốt trên eBay
Librem 5 và PinePhone có mức hỗ trợ khá tốt, nhưng các thiết bị Android cũ như OnePlus 6T có thể cho hiệu năng trên giá thành tốt hơn. Trước khi mua, cần kiểm tra xem các chức năng quan trọng có hoạt động không
Có thể chạy các app Android phổ biến bằng Waydroid
Phương án thay thế là xác thực SMS cũng đang biến mất vì không an toàn; xét về bảo mật thì đó là hướng đi đúng, nhưng lại thiếu những phương thức khác đủ khả dụng