- GrapheneOS đã khắc phục trong bản cập nhật mới một lỗ hổng bỏ qua VPN trên Android, vốn có thể làm lộ địa chỉ IP thực ngay cả khi đã bật “Always-On VPN” và “Block connections without VPN”
- Lỗ hổng bắt nguồn từ tính năng đóng kết nối QUIC trong ngăn xếp mạng của Android 16, cho phép ứng dụng thông thường chỉ với các quyền chuẩn đăng ký UDP payload vào
system_server
- Khi socket UDP của ứng dụng bị hủy, system_server có đặc quyền sẽ gửi trực tiếp payload đã lưu qua giao diện mạng vật lý thay vì đường hầm VPN, từ đó vượt qua cơ chế khóa VPN
- Google phân loại vấn đề này là “Won’t Fix (Infeasible)” và “NSBC”, đồng thời giữ nguyên lập trường rằng nó không đáp ứng tiêu chí của khuyến cáo bảo mật Android
- Trong release 2026050400, GrapheneOS đã vô hiệu hóa “registerQuicConnectionClosePayload optimization”; bản phát hành này cũng gồm bản vá bảo mật Android tháng 5/2026, cải tiến hardened_malloc, cập nhật nhân Linux và bản sửa backport cho libpng CVE-2026-33636
Cách lỗ hổng hoạt động
- Theo phân tích kỹ thuật của Yusuf, API dễ tổn thương cho phép một ứng dụng thông thường chỉ có các quyền được cấp tự động là INTERNET và ACCESS_NETWORK_STATE đăng ký payload UDP tùy ý vào
system_server
- Sau đó, khi socket UDP của ứng dụng bị hủy, tiến trình system_server có đặc quyền của Android sẽ gửi trực tiếp payload đã lưu qua giao diện mạng vật lý của thiết bị thay vì đường hầm VPN
- Do
system_server hoạt động với quyền mạng nâng cao và được miễn khỏi các giới hạn định tuyến VPN, gói tin này sẽ bỏ qua hoàn toàn cơ chế khóa VPN của Android
- Nhà nghiên cứu bảo mật lowlevel/Yusuf đã trình diễn lỗ hổng trên Pixel 8 chạy Android 16 với Proton VPN và chế độ khóa Android cùng được bật
- Ứng dụng đó làm rò rỉ địa chỉ IP công khai thực của thiết bị tới máy chủ từ xa ngay cả khi bảo vệ VPN đã được bật đầy đủ
Nguyên nhân và cách Google xử lý
- Google đã đưa vào một tính năng để ứng dụng có thể đóng phiên QUIC đúng cách khi socket bị hủy ngoài dự kiến
- Cách triển khai chấp nhận payload tùy ý nhưng không xác minh liệu payload đó có phải là khung QUIC CONNECTION_CLOSE hợp lệ hay không
- Cách triển khai ban đầu cũng không kiểm tra liệu ứng dụng có bị giới hạn chỉ dùng lưu lượng qua VPN hay không
- Nhà nghiên cứu đã báo cáo vấn đề này cho đội bảo mật Android, nhưng Google phân loại nó là “Won’t Fix (Infeasible)” và “NSBC” (Not Security Bulletin Class)
- Google cho rằng vấn đề này không đạt ngưỡng để được đưa vào khuyến cáo bảo mật Android
- Nhà nghiên cứu đã yêu cầu xem xét lại, lập luận rằng bất kỳ ứng dụng nào cũng có thể làm rò rỉ thông tin mạng có thể định danh chỉ với các quyền chuẩn, nhưng Google vẫn giữ nguyên lập trường và phê duyệt công bố vào ngày 29 tháng 4
Cập nhật và biện pháp giảm thiểu của GrapheneOS
- GrapheneOS là một hệ điều hành dựa trên Android tập trung vào quyền riêng tư và bảo mật, chủ yếu được phát triển cho thiết bị Google Pixel, phục vụ nhóm người dùng muốn có sandbox ứng dụng mạnh hơn, biện pháp giảm thiểu khai thác tốt hơn và ít phụ thuộc hơn vào dịch vụ Google
- Trong release 2026050400, GrapheneOS đã vô hiệu hóa hoàn toàn tối ưu hóa nói trên để ngăn rò rỉ VPN
- Yusuf cho biết GrapheneOS đã hoàn tất việc phát hành bản sửa trong chưa đầy một tuần
- Ngoài bản sửa rò rỉ VPN, bản phát hành mới nhất còn bao gồm toàn bộ mức bản vá bảo mật Android tháng 5/2026
- Bản cập nhật cũng bao gồm nhiều cải tiến hardened_malloc, cập nhật nhân Linux trên các nhánh 6.1, 6.6 và 6.12 của Android, cùng bản sửa backport cho CVE-2026-33636 của libpng
- Bản dựng trình duyệt Vanadium mới và các hạn chế Dynamic Code Loading được mở rộng cũng được cung cấp cùng lúc
- Người dùng Android mặc định có thể tạm thời giảm thiểu vấn đề bằng cách vô hiệu hóa cờ DeviceConfig close_quic_connection thông qua ADB
- Cách обход này yêu cầu quyền truy cập của nhà phát triển
- Nếu Google xóa cờ tính năng này trong một bản cập nhật tương lai, biện pháp giảm thiểu này có thể sẽ không còn duy trì được
1 bình luận
Ý kiến trên Hacker News
Nếu
system_serverchạy với quyền mạng cao và được miễn khỏi các hạn chế định tuyến VPN, thì trên Android VPN về cơ bản không còn là VPN nữaNgoài lỗi này ra, tôi cũng tò mò liệu các hệ điều hành khóa chặt khác có hoạt động theo cách tương tự không
Mullvad và các bên khác cũng đã bàn về vấn đề này từ lâu
Điều tôi lo là mọi người nhìn cùng một từ được viết giống nhau nhưng không nhận ra sự khác biệt về ngữ cảnh, rồi mở rộng mô hình tin cậy của máy tính sang kiểu tin cậy giữa con người một cách sai lầm
Tôi không rõ có lỗ hổng hay kẽ hở nào cho phép gửi trực tiếp lưu lượng đến đích tùy ý hay không
system_servervà các đường vòng khác khó đến mức nàoTương tự Manifest V3, việc ngăn chặn theo dõi lén không phù hợp với lợi ích của Google
Những hạn chế như vậy gây hại cho mô hình kinh doanh của họ
Lý do kỹ thuật khiến vấn đề này nghiêm trọng là rò rỉ xảy ra trong
system_server, một tiến trình có đặc quyềnChế độ khóa tích hợp của Android nêu rõ rằng không có lưu lượng nào được vượt qua VPN. Nếu chính hệ thống gửi gói tin qua giao diện vật lý, thì lời hứa đó bị phá vỡ ở cấp kernel chứ không phải không gian người dùng, nên khó có thể nói đây “không đến mức thông báo bảo mật”
Nếu Google đã cho phép công bố vào ngày 29 tháng 4, thì thật ngạc nhiên là họ vẫn giữ embargo và dời việc phát hành bản sửa sang tận tháng 5
Tôi không hiểu vì sao họ không công bố ngay
Dù thích hay không, GrapheneOS phụ thuộc vào Android do Google kiểm soát
Tôi biết là có lý do kinh doanh xấu đằng sau, nhưng không hiểu làm sao họ vẫn có thể giữ thể diện khi xếp rò rỉ VPN là không phải vấn đề bảo mật
Ban đầu VPN là để truy cập mạng riêng hay mạng công việc thông qua một mạng khác, ví dụ kết nối giữa các văn phòng hoặc từ nhà vào văn phòng. Chỉ về sau nó mới biến thành một dạng công cụ bảo mật
Nếu nhìn mã VPN theo kiểu “chỉ cần điện thoại truy cập được máy in ở văn phòng qua 5G là ổn”, thì đây có thể chỉ là một lỗi nhỏ khiến kết nối QUIC không đóng đúng cách. Ngược lại, nếu coi “đường hầm WireGuard này phải bảo vệ danh tính của tôi bằng mọi giá” hoặc “nó phải là bản sao chính xác của toàn bộ lưu lượng qua Internet”, thì đây là vấn đề lớn
Tôi không nghĩ Android VPN, hay thực ra gần như bất kỳ VPN nào, từng được thiết kế như một biện pháp quyền riêng tư hay bảo mật. Đặc biệt là trước các ứng dụng có thể chạy mã trên thiết bị, và bản thân thiết bị cũng có nhiều tương tác mạng khác nhau, bao gồm cả bên trong chip modem
Việc Google đóng lỗi lại là một sai lầm, nhưng tôi có thể hiểu vì sao họ không coi đó là lỗi bảo mật trong chương trình bug bounty
Google là công ty quảng cáo kiêm nhà thầu tấn công, nên việc người dùng VPN làm rò gói tin có lợi cho họ ở cả hai mặt
Điều này cũng giống như Meta gỡ bỏ mã hóa đầu-cuối
Nó gần như là: “không, chúng tôi muốn nhìn thấy toàn bộ những gì bạn nói và làm”
Tôi muốn biết cách tốt để kiếm một chiếc điện thoại GrapheneOS
Tôi muốn thử GrapheneOS nhưng vẫn ngần ngại mua hẳn một chiếc Pixel. Hàng cũ thì ngay cả dòng “a” thường cũng hơn 300 USD, hoặc phải lùi vài thế hệ. Còn phải xem có mở khóa bootloader được không. Tôi vẫn chưa sẵn sàng bỏ 449 USD cho Pixel 10a mới
Tham khảo thêm, lúc Google Fi ra mắt tôi mua Pixel 10a với giá khoảng 300 USD
Pixel 9a gần như là cùng một thiết bị và vẫn đang được bán mới
Mua máy mới ở cửa hàng bán lẻ bình thường hoặc Google Store thay vì cửa hàng nhà mạng sẽ chắc chắn hơn
Máy cũ gần như là đánh bạc vì vấn đề xử lý mở khóa OEM, nên hãy kiểm tra chính sách đổi trả và xác minh trước khi mua rằng mục mở khóa OEM có thể truy cập được
Về cơ bản, hãy mua thiết bị từ Pixel 6 trở lên mà chắc chắn có thể mở khóa bootloader. Tuy vậy Pixel 6 sắp chỉ còn hỗ trợ tối thiểu, nên tôi khuyên dùng từ Pixel 7 trở lên. Phần lớn máy cũ là không thể mở khóa bootloader
Nói cách khác, tốt nhất là mua trực tiếp từ Google, hoặc mua trên eBay những máy đã cài sẵn GrapheneOS/CalyxOS/LineageOS, hoặc mua thiết bị mà người bán nói rõ là có thể mở khóa bootloader
Cá nhân tôi thấy nếu người bán chưa tự nhắc đến điều đó thì yêu cầu họ kiểm tra bootloader hầu như vô ích. Gần như chẳng ai muốn làm quy trình kiểm tra, và câu trả lời thường rất có thể là “không được”, hoặc họ hiểu sai câu hỏi rồi chỉ trả lời là “điện thoại unlock”, hoặc họ đã quá mệt với kiểu câu hỏi này
Đã có công việc đang diễn ra để hỗ trợ thêm nhiều phần cứng điện thoại, và trong một thời gian người ta vẫn chỉ đoán đó sẽ là thương hiệu nào
Tôi đã mua một chiếc Pixel 6 cũ giá rẻ để thử GrapheneOS nhưng không thích lắm
Tôi cảm thấy trải nghiệm người dùng của LineageOS tốt hơn nhiều. Cấu trúc trình quản lý gói giống như búp bê Nga, khá kỳ quặc. “App Store” mặc định chỉ có vài chương trình cơ bản, một trong số đó lại là Accrescent, tức là một trình quản lý gói khác, nhưng số lượng ứng dụng vẫn quá ít nên lại cần thêm một trình quản lý gói nữa. Có vẻ phía GrapheneOS thích Obtainium hơn F-Droid, mà điều này cũng là một quyết định kỳ lạ theo tôi
Tôi thích một trình quản lý gói hoàn toàn mã nguồn mở hơn nhiều, và việc build từ source ở bên ngoài thay vì tin vào các gói trên GitHub, đồng thời build tái lập nếu có thể, thực sự có giá trị. Mô hình bảo mật của GrapheneOS trông hơi tập trung hóa một cách kỳ lạ. Những lợi ích được báo cáo về quyền riêng tư và bảo mật thì khó tự mình đánh giá
Tôi không hiểu vì sao lại cố chấp rằng nhất định phải có một app store mặc định, cố định và cài sẵn
Vận hành một app store cũng vất vả chẳng kém việc duy trì một nhánh Android, và khi đã có F-Droid, Play Store cùng Aurora Store, Obtainium và nhiều lựa chọn khác, thì khó mà trách các nhà phát triển GrapheneOS không bỏ ra thêm một lượng công sức khổng lồ
Trạng thái mặc định chỉ có launcher và hệ điều hành tối thiểu, như vậy là đủ cho người theo chủ nghĩa tối giản
Nếu cần thêm, người dùng tự quyết định sẽ đi đâu. Tôi gọi đó là trao quyền cho người dùng, còn có vẻ bạn gọi đó là bất tiện. Nếu vậy thì có lẽ hệ điều hành đó không phù hợp với bạn
“Mã nguồn mở” về cơ bản chỉ là một thuật ngữ giấy phép
“App Store” của GrapheneOS tồn tại để cung cấp những ứng dụng cơ bản nhất cần cho việc sử dụng thông thường. Lý do Accrescent được phân phối ở đó là vì nó tuân theo baseline bảo mật của Android với tư cách là một kho ứng dụng thực thụ, còn F-Droid và Aurora Store thì không
Tôi không thấy có nhiều giá trị lớn trong cách bên thứ ba build ứng dụng để kiểm tra hành vi độc hại như F-Droid. Kiểu kiểm tra đó không đáng tin cậy và từng bị qua mặt. Đó cũng là một trong những lý do WireGuard không còn trên F-Droid nữa. Nếu bạn không đủ tin ứng dụng để nhận trực tiếp từ nhà phát triển, thì tốt nhất là đừng dùng ứng dụng đó
Các lợi ích về quyền riêng tư và bảo mật của GrapheneOS được thiết kế để gần như không nhìn thấy đối với người dùng trung bình. Ví dụ là bộ cấp phát bộ nhớ được gia cố và memory tagging extension để ngăn lỗi hỏng bộ nhớ, cùng khả năng cài Google Play trong sandbox để dùng dịch vụ Google mà không để Google kiểm soát toàn bộ thiết bị
App Store của GrapheneOS tồn tại để đảm nhiệm vai trò kho ứng dụng bên thứ nhất mà AOSP yêu cầu. Nó cũng có vai trò cập nhật ứng dụng bên thứ nhất tách khỏi cập nhật hệ điều hành, và trong một số trường hợp còn mirror ứng dụng
Accrescent được mirror vì tập trung vào quyền riêng tư và bảo mật. Hiện vẫn đang ở trạng thái alpha và việc gửi ứng dụng đang đóng, nhưng sẽ sớm mở lại
Google Play được mirror để tương thích với các ứng dụng cần Google Play, cũng như để truy cập Play Store
Lý do cộng đồng GrapheneOS thích Obtainium là vì nó có thể lấy ứng dụng do chính nhà phát triển ký từ những nơi như GitHub. F-Droid thì ký và build gần như toàn bộ ứng dụng trong kho chính của họ bằng hạ tầng build cũ kỹ và cơ chế điều phối yếu kém
Mô hình bảo mật của GrapheneOS kế thừa mô hình bảo mật của AOSP rồi gia cố thêm trên nền đó
GrapheneOS có rất nhiều triển khai kỹ thuật ấn tượng, nhưng phía Calyx có vẻ xử lý nhiều thứ đơn giản hơn và gần với Android gốc hơn
GrapheneOS nói rằng để “sửa rò rỉ VPN”, họ đã vô hiệu hóa tối ưu hóa
registerQuicConnectionClosePayloadvà trên các thiết bị Pixel được hỗ trợ thì về cơ bản đã vô hiệu hóa vector tấn công nàyTức là GrapheneOS đã “sửa” rò rỉ bằng cách tắt tối ưu hóa đó
Trước đây trên HN người ta từng ca ngợi QUIC, và chê điểm thấp những bình luận hỏi QUIC có lợi nhất cho ai. Việc dùng QUIC có thể phù hợp với lợi ích của người khác, nhưng với tôi thì đánh đổi đó không xứng nên tôi chặn lưu lượng QUIC
QUIC đôi khi được bật mặc định trong phần mềm do Google phân phối như Android, và trong một số trường hợp còn không có cách để tắt
Thứ GrapheneOS loại bỏ chỉ là cách để ứng dụng yêu cầu hệ điều hành tự động đóng kết nối QUIC trong các tình huống như ứng dụng bị chết. Nhìn từ phía máy chủ thì đó là một tối ưu hóa vì tránh việc kết nối bị treo mở và giữ tài nguyên rồi chỉ đóng sau khi hết thời gian nhàn rỗi, nhưng đó không phải tối ưu hóa từ góc nhìn máy khách
Ngoài ra GrapheneOS cũng đã sửa khoảng 5 rò rỉ VPN khác và vẫn đang tiếp tục sửa thêm. Cách triển khai VPN hiện tại của Android là VPN theo profile, nhưng profile vẫn chưa dùng network namespace riêng, và bộ phân giải DNS cùng nhiều dịch vụ trung tâm phải tự xử lý hỗ trợ VPN cho đúng nên rất dễ rò rỉ
Trong tương lai họ định cải thiện kiến trúc VPN để nó có khả năng kháng rò rỉ rất mạnh. Cũng sẽ có hỗ trợ chạy ứng dụng hay nhóm ứng dụng trong máy ảo, điều này có thể mang lại bảo vệ mạnh hơn
Bản thân QUIC là rất tốt, và đây gần như không phải là tính năng của giao thức mà là tính năng của Google Android, một hệ điều hành giám sát
Hơn nữa, khi kiểm tra trên hệ điều hành trước bản phát hành mới nhất thì nó thậm chí còn không hoạt động đúng
Android gốc là spyware và adware
Trước đây loại phần mềm như vậy sẽ bị gọi là độc hại và bị gỡ bỏ, nhưng giờ nó lại là mặc định
Họ biết 99% người dùng không quan tâm, nên điểm gây áp lực duy nhất có lẽ là các hãng sản xuất điện thoại. Tôi cảm thấy bất lực vì không có sức ảnh hưởng tới bất kỳ ai có thể tạo ra tác động có ý nghĩa trong lĩnh vực này