Lỗ hổng Android zero-click: Một tin nhắn SMS đủ để đánh sập điện thoại từ xa

Công nghệ29 tháng 10, 2026·6 phút đọc

Một lỗ hổng trong thành phần Android Telephony cho phép kẻ tấn công gửi một tin nhắn WAP Push SMS dị dạng để làm sập tiến trình com.android.phone từ xa, không cần người dùng tương tác. Nghiêm trọng hơn, khi gửi dồn dập khoảng 30 tin, cơ sở dữ liệu SMS có thể bị hỏng khiến điện thoại khởi động lại vẫn liên tục gặp lỗi. Google đã phân loại vấn đề này là không phải lỗ hổng bảo mật qua ba lần xử lý.

Một nhà nghiên cứu bảo mật vừa công bố lỗ hổng nghiêm trọng trên Android: chỉ cần một tin nhắn SMS dị dạng gửi tới số điện thoại nạn nhân, tiến trình điện thoại hệ thống có thể bị sập ngay lập tức mà người dùng không hề hay biết. Đáng chú ý, Google đã từ chối sửa lỗi này qua nhiều lần báo cáo, buộc nhà nghiên cứu phải công khai toàn bộ chi tiết.

Cơ chế gây lỗi: một phép tính tràn số

Lỗ hổng nằm trong lớp xử lý Android Telephony, cụ thể ở hàm WapPushOverSms.decodeWapPdu(). Khi nhận một tin nhắn WAP Push, hệ thống đọc độ dài phần header WSP dưới dạng uintvar — một kiểu mã hóa số nguyên có độ dài thay đổi.

Giá trị này được trả về dưới dạng long, sau đó bị ép sang int mà không có bất kỳ kiểm tra phạm vi nào, rồi dùng trực tiếp làm kích thước cấp phát mảng byte mới.

Với chuỗi uintvar 5 byte 88 80 80 80 00, giá trị giải mã là 0x80000000. Khi ép sang số nguyên có dấu 32-bit, con số này trở thành -2147483648. Việc cấp phát new byte[-2147483648] sẽ ném ra ngoại lệ NegativeArraySizeException không được bắt trên luồng chính của tiến trình điện thoại, khiến com.android.phone bị kill ngay lập tức.

Tin nhắn được gửi dưới dạng data SMS và không bao giờ hiển thị cho người dùng: không có gì trong hộp thư đến, nạn nhân cũng không thấy số của kẻ gửi.

Nhà nghiên cứu cho biết đã thử nghiệm trên nhiều hãng và mẫu máy khác nhau — Pixel 9 với firmware tháng 4/2026, nhiều dòng Samsung Galaxy và Galaxy A — với tỷ lệ tái hiện 100%.

Từ sập tạm thời đến "khóa cứng" thiết bị

Một tin nhắn đơn lẻ chỉ gây gián đoạn tạm thời. Nhưng nếu gửi dồn dập khoảng 30 tin liên tiếp, hậu quả nghiêm trọng hơn nhiều: các lần sập xen kẽ với thao tác ghi của nhà cung cấp telephony vào kho SMS, chạm vào race condition và làm hỏng cơ sở dữ liệu SQLite lưu tin nhắn của thiết bị.

Khi cơ sở dữ liệu đã hỏng, com.android.phone không cần thêm tin nhắn mới để lỗi nữa — nó sập ngay khi khởi động vì đọc kho dữ liệu bị tổn hại. Điện thoại lúc này mất hoàn toàn chức năng liên lạc, và khởi động lại không khắc phục được.

Phần nguy hiểm nhất nằm ở quy trình phục hồi: khôi phục cài đặt gốc (factory reset) chỉ giúp tạm thời, vì nhà mạng sẽ gửi lại payload chưa được xác nhận và tái kích hoạt lỗi. Với thiết bị dùng eSIM, khi SIM không thể tháo ra lắp sang máy khác, việc phục hồi càng khó khăn hơn — và với người dùng không rành kỹ thuật thì gần như nằm ngoài tầm với.

Hệ lụy về khả năng gọi khẩn cấp

Việc mất cuộc gọi không chỉ là bất tiện khi một trong các cuộc gọi đó là tới dịch vụ khẩn cấp. Trong lúc bị tấn công hoặc khi đã bị hỏng cơ sở dữ liệu, thiết bị không thể gọi tới số khẩn cấp một cách đáng tin cậy.

Tại một số quốc gia, quy định pháp lý còn khiến tình hình éo le hơn. Ở Australia, theo Đạo luật Dịch vụ Gọi khẩn cấp do ACMA quản lý, nhà mạng buộc phải xác định các điện thoại không thể gọi số khẩn cấp, hỗ trợ khách hàng chuyển sang thiết bị hoạt động, và ngắt dịch vụ với máy bị ảnh hưởng. Telstra nêu rõ họ phải chặn các máy không gọi được số 000, thông báo cho khách hàng và khóa thiết bị nếu sau 28 ngày không có biện pháp khắc phục.

Hệ quả khá trớ trêu: biện pháp xử lý theo quy định với một chiếc điện thoại không gọi được số khẩn cấp là cắt nó khỏi mạng, chứ không phải vá hệ điều hành. Nghĩa là kẻ tấn công có thể khiến thiết bị của nạn nhân bị chính nhà mạng chặn dịch vụ cho đến khi có bản vá. Khung pháp lý này được siết chặt từ năm 2024 sau sự cố tắt sóng 3G, khi một số điện thoại vẫn gọi thường được nhưng không gọi được dịch vụ khẩn cấp — đúng trạng thái mà lỗ hổng này tạo ra.

Bản vá đơn giản nhưng bị từ chối

Biện pháp khắc phục chỉ là thêm kiểm tra phạm vi trước khi ép kiểu trong WapPushOverSms.java (dòng 217), được gửi cho Google ngay từ ngày báo cáo đầu tiên.

Báo cáo được nộp qua chương trình Android & Google Devices VRP và gửi lại hai lần dưới dạng khiếu nại về việc phân loại sai. Qua ba ticket và bốn kỹ sư, Google vẫn phân loại đây là vấn đề không thuộc bảo mật.

Nhà nghiên cứu đã giữ kín thông tin vượt xa khung 90 ngày của VRP trước khi công bố đầy đủ, nhằm giúp người dùng, nhà mạng và các hãng sản xuất thiết bị đánh giá rủi ro và có biện pháp phòng ngừa.

Ứng dụng PoC và cảnh báo

Mã nguồn đầy đủ cùng ứng dụng PoC Android đã được công bố trên GitHub. Ứng dụng có khả năng tạo PDU WAP Push dị dạng và gửi dưới dạng data SMS tới số mục tiêu.

Cảnh báo: đây là công cụ có khả năng tấn công thực tế. Kho mã chỉ được công bố nhằm mục đích nghiên cứu bảo mật, giáo dục và kiểm thử phòng thủ.

  • Chỉ thử nghiệm trên thiết bị bạn sở hữu hoặc được phép kiểm thử rõ ràng
  • Sử dụng với người khác là hành vi phạm pháp
  • Can thiệp vào khả năng gọi dịch vụ khẩn cấp là tội hình sự nghiêm trọng tại nhiều quốc gia
  • Phần mềm phát hành theo giấy phép Apache 2.0, không kèm bảo hành; tác giả không chịu trách nhiệm cho bất kỳ sử dụng nào

Góc nhìn cho người dùng Việt Nam

Câu chuyện này là lời nhắc nhở rằng tính năng gọi khẩn cấp — điều thường được coi là hiển nhiên — lại có thể bị vô hiệu hóa từ xa bởi một tin nhắn. Với người dùng Android tại Việt Nam, việc theo dõi các bản cập nhật bảo mật hàng tháng từ nhà sản xuất, và ưu tiên thiết bị còn được hỗ trợ cập nhật dài hạn, trở nên quan trọng hơn bao giờ hết.

Trường hợp này cũng đặt câu hỏi về cách các chương trình săn lỗi được vận hành: khi một lỗ hổng có thể gây hậu quả nghiêm trọng bị phân loại là "không phải bảo mật", áp lực công khai trở thành công cụ cuối cùng để thúc đẩy bản vá.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗