Báo cáo công bố lỗ hổng bảo mật zero-click mang tên SMS of Death của chuyên gia an ninh mạng Mark Blaszczyk đang gióng lên hồi chuông cảnh báo đỏ đối với toàn bộ hệ sinh thái di động Android. Sự cố kỹ thuật này không chỉ phơi bày điểm yếu cấu trúc trong tầng viễn thông cốt lõi của hệ điều hành mã nguồn mở, mà còn làm dấy lên những tranh luận gay gắt về quy trình đánh giá mức độ nghiêm trọng của các chương trình săn lỗi nhận thưởng (Bug Bounty) từ các tập đoàn công nghệ lớn.
Cơ chế lỗi tràn số nguyên trong tầng xử lý WapPushOverSms
Về mặt kỹ thuật, lỗ hổng phát sinh tại thành phần WapPushOverSms, cụ thể là bên trong hàm decodeWapPdu chịu trách nhiệm phân tích cú pháp các gói dữ liệu WAP Push nhận qua giao thức SMS trên cổng logic 2948. Khi đọc trường độ dài tiêu đề (header length) của gói tin, hệ thống Android thực hiện ép kiểu giá trị này sang một số nguyên 32-bit (32-bit signed integer) nhưng lại bỏ qua bước kiểm tra phạm vi biên (range/bounds check) trước khi sử dụng nó để khởi tạo kích thước mảng bộ nhớ.
Kẻ tấn công có thể dễ dàng chế tạo một gói tin mang tải trọng độc hại (payload) chỉ dài 8 byte, trong đó chứa một giá trị 5-byte được tính toán đặc biệt để chuyển hóa thành số âm sau khi ép kiểu. Do Java/Android không thể khởi tạo mảng với kích thước âm, hệ thống sẽ lập tức ném ra ngoại lệ ngoại vi không được bắt giữ (uncaught exception). Hậu quả trực tiếp là tiến trình hệ thống quan trọng bậc nhất com.android.phone – nơi quản lý toàn bộ giao tiếp mạng viễn thông, gọi thoại và dữ liệu di động – bị ép dừng đột ngột (crash).
Phản ứng dây chuyền từ RescueParty và bài toán từ chối dịch vụ từ xa
Tính chất nguy hiểm của SMS of Death nằm ở việc nó tạo ra một cuộc tấn công từ chối dịch vụ từ xa (Remote Denial of Service – DoS) có tính chất khuếch đại tự nhiên. Do com.android.phone bị sập trước khi hệ thống kịp gửi gói tin xác nhận chuyển giao (delivery acknowledgement) ngược về trạm phát sóng cơ sở, trung tâm tin nhắn ngắn (SMSC) của nhà mạng viễn thông sẽ tự động đưa tin nhắn vào hàng đợi và gửi lại liên tục theo thuật toán thử lại (retry policy). Điều này dẫn đến tình trạng thiết bị nạn nhân bị ngắt kết nối dịch vụ liên tục trong suốt nhiều ngày.
Khi mật độ tin nhắn gửi đến đạt ngưỡng khoảng 20 gói tin, hệ thống giám sát tính toàn vẹn của Android mang tên RescueParty sẽ can thiệp. Nhận thấy tiến trình hệ thống liên tục đổ vỡ trong chu kỳ ngắn, RescueParty sẽ buộc thiết bị khởi động lại và sau một số lần thử không thành công sẽ kích hoạt chế độ khôi phục (Recovery Mode) kèm thông báo đề xuất xóa phân vùng dữ liệu người dùng. Đối với các tổ chức và doanh nghiệp vận hành mạng lưới thiết bị làm việc di động, cuộc tấn công này có thể làm tê liệt hoàn toàn các hệ thống xác thực hai yếu tố dựa trên mã SMS (SMS OTP) và gây gián đoạn thông tin liên lạc khẩn cấp.
Khủng hoảng phân mảnh bản vá và khoảng trống hỗ trợ trên Android cũ
Lỗ hổng này ảnh hưởng trên diện rộng từ Android 12 đến Android 17. Mặc dù các kỹ sư của Google đã âm thầm hoàn thiện đoạn mã sửa lỗi (commit 735d967 với việc bổ sung bộ lọc kiểm tra giới hạn) từ tháng 6 năm 2026, nhưng việc định mức mức độ rủi ro ban đầu bị đánh giá thấp đã khiến bản vá chính thức bị trì hoãn tới các bản cập nhật bảo mật tháng 10 và tháng 11 năm 2026.
Thách thức lớn nhất hiện nay thuộc về sự phân mảnh của hệ sinh thái. Trong khi các dòng máy Google Pixel và bản phân phối bảo mật như GrapheneOS đã nhanh chóng nhận được bản vá, các nhà sản xuất OEM như Samsung, Xiaomi hay Motorola cần thêm thời gian để kiểm thử và phân phối bản cập nhật qua giao thức OTA. Đáng lo ngại hơn, hàng trăm triệu thiết bị đang hoạt động trên nền tảng Android 12 và Android 13 đã hết thời hạn hỗ trợ chính thức sẽ không nhận được bản vá từ Google, buộc các nhà mạng viễn thông phải xem xét giải pháp lọc các gói tin WAP Push dị thường trực tiếp từ tầng cổng truyền thông mạng (network gateway) để ngăn chặn nguy cơ bị khai thác trên diện rộng.
