OEMpocalypse: Ứng dụng Android không đặc quyền có thể root trên Samsung, Xiaomi và nhiều hãng khác

Một nhà nghiên cứu bảo mật đã trình diễn cách đưa một ứng dụng Android thông thường, không đặc quyền, lên quyền root trên hàng loạt thiết bị flagship của Samsung, Xiaomi, Oppo, OnePlus và Realme. Điểm đáng chú ý là toàn bộ chuỗi khai thác chỉ nhắm vào mã do chính các hãng sản xuất thiết bị (OEM) viết, chứ không phải vào nhân Linux chung hay driver chipset.

Ứng dụng không đặc quyền khai thác lên root trên Android

Bối cảnh: Bề mặt tấn công của kernel Android

Trên Android, mọi ứng dụng bên thứ ba đều chạy trong một môi trường cách ly gọi là untrusted_app. Ba lớp phòng vệ cùng lúc giới hạn những gì ứng dụng này có thể chạm tới: DAC (kiểm soát truy cập tùy ý theo mô hình UID riêng cho từng ứng dụng), SELinux (lớp kiểm soát truy cập bắt buộc) và seccomp (lọc lời gọi hệ thống).

Kết quả là phần lớn kernel, đặc biệt là tầng driver, hoàn toàn không thể truy cập nếu chưa di chuyển sang một miền đặc quyền cao hơn. Nhà nghiên cứu Lukas Maar chia bề mặt tấn công này thành ba nhóm chính:

• Mã Linux chung dùng trên mọi thiết bị Android, ví dụ io_uring, ngăn xếp mạng hay lõi quản lý bộ nhớ.
• Driver chipset như GPU (Mali, Adreno KGSL), DSP hoặc NPU, vốn được mở trực tiếp cho ứng dụng vì lý do hiệu năng.
• Mã riêng của OEM như driver và dịch vụ kernel do Samsung, Xiaomi hay Oppo tự phát triển.

Vì sao nên nhắm vào mã của OEM?

Theo tác giả, một chuỗi khai thác lý tưởng từ untrusted_app lên root cần đạt ba tính chất: độ tin cậy (thành công gần như 100% bất kể phòng vệ nào được bật), tính di động (ít phải điều chỉnh theo phiên bản kernel, OEM hay chipset) và tính phổ quát (một khai thác dùng được cho càng nhiều thiết bị càng tốt).

Lỗ hổng trong mã Linux chung tuy phổ quát nhưng thường chỉ cho ra các nguyên thủy hạn chế ở mức slab, đòi hỏi nhiều thủ thuật như dọn heap, vượt cache hay tìm rò rỉ thông tin. Ngược lại, lỗi trong driver chipset thường cho nguyên thủy mạnh hơn ở mức trang nhớ, nhưng độ phủ thiết bị rất khác nhau giữa các chip.

Mã của OEM lại có một lợi thế đặc biệt: nó gắn với lớp phần mềm của hãng (One UI, HyperOS, ColorOS) chứ không gắn với chip bên dưới. Vì vậy cùng một thành phần thường xuất hiện trên toàn bộ dòng sản phẩm của hãng đó, bất kể máy dùng Snapdragon, Exynos hay Dimensity.

Chiến lược rất đơn giản: tìm một lỗi page Use-After-Free (UAF) trong driver kernel của OEM, và nếu chính sách SELinux của hãng chặn driver đó sau một miền đặc quyền, hãy thoát khỏi sandbox bằng một lỗi logic của chính OEM trước.

Hai giai đoạn của chiến lược

Giai đoạn 1: Thoát khỏi sandbox

Dù Android phân tách ứng dụng, dịch vụ hệ thống và tiến trình nền thành các UID và miền SELinux riêng, chúng vẫn phải giao tiếp với nhau qua Binder, intent, content provider hay socket nội bộ. Mỗi điểm giao tiếp liên tiến trình như vậy là một nơi mà bên gọi ít đặc quyền hơn gửi dữ liệu cho bên nhận nhiều đặc quyền hơn.

Các hãng OEM bổ sung rất nhiều ứng dụng, dịch vụ và tiến trình nền của riêng mình, mỗi thứ đều có tập điểm giao tiếp riêng. Chỉ cần một lỗi logic như thiếu kiểm tra người gọi, vô tình xuất khẩu một thành phần, hay không xác thực đường dẫn tệp, là đủ để vượt qua ranh giới đặc quyền.

Điểm mấu chốt là lỗi kiểu này nằm hoàn toàn trong mã người dùng của OEM, không phụ thuộc chipset, phiên bản kernel hay model máy cụ thể.

Giai đoạn 2: Lỗi page UAF trong driver kernel

Giai đoạn hai nhắm vào lỗi page UAF trong driver kernel của OEM. Đây là lỗi để lại một tham chiếu vẫn trỏ tới một trang vật lý sau khi kernel đã giải phóng và cấp phát lại trang đó.

Nguyên thủy thu được gần như độc lập với các yếu tố thường khiến việc khai thác kernel Android phải may đo cho từng mục tiêu:

• Nó hoạt động ở mức trang nhớ, nên các kỹ thuật gia cố tập trung vào slab như CONFIG_SLAB_BUCKETS hay CONFIG_RANDOM_KMALLOC_CACHES không cản trở được.
• Nó thường không cần rò rỉ KASLR, vì đọc ghi qua ánh xạ đã nắm giữ thay vì truy xuất con trỏ kernel.
• Đây là khai thác chỉ dữ liệu, nên các lớp bảo vệ luồng điều khiển như CFI không giới hạn được.
• Hành vi của bộ cấp phát trang tương đối ổn định giữa các phiên bản kernel. Trong các chuỗi này, cùng một đoạn mã thu hồi và sắp xếp trang chạy không đổi từ kernel 5.15 đến 6.12.

Mức độ ảnh hưởng

Tác giả đã hiện thực hóa chiến lược này ba lần, mỗi lần cho một nhóm OEM lớn, và tìm ra nhiều lỗ hổng khác nhau trên đường đi:

• Samsung: phủ toàn bộ flagship, ít nhất từ Galaxy S23 đến S26 và dòng Z gần đây.
• Xiaomi: phần lớn thiết bị từ tầm trung đến flagship.
• Oppo, OnePlus, Realme: các flagship gần đây như Oppo Find X9 Ultra và OnePlus Ace 6 Ultra.

Chuỗi khai thác chạy trên thiết bị khóa bootloader nguyên bản

Các bản demo đều chạy trên thiết bị khóa bootloader, dùng ảnh hệ thống gốc đã ký. Sau khi khai thác thành công, ứng dụng thu được shell root với dấu hiệu nhận biết rõ ràng:

User:            uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
SELinux:         Permissive
Verified boot:   green
Bootloader lock: 1
VBMeta state:    locked

Dòng Verified boot: green, Bootloader lock: 1 và VBMeta state: locked là những thông tin quan trọng nhất, xác nhận thiết bị đang chạy ảnh hệ thống đã ký với bootloader bị khóa.

Đánh đổi và bài học phòng thủ

Nhược điểm của chiến lược này là không xuyên OEM: một chuỗi cho Samsung không dùng được trên Xiaomi, nên phủ ba hãng đồng nghĩa với ba chuỗi độc lập. Ngoài ra, ngay trong một hãng, không phải thành phần nào cũng có mặt trên mọi model, chẳng hạn Samsung bật các tầng phần mềm khác nhau giữa flagship và dòng A tầm trung.

Mỗi chuỗi hai giai đoạn phụ thuộc vào ít nhất hai lỗ hổng độc lập. Khi bất kỳ lỗi nào bị vá, chuỗi đó cần một lỗ hổng thay thế. Duy trì tập lỗ hổng còn "sống" là công việc liên tục.

Về phía phòng thủ, page UAF là một lớp lỗi vốn rất khó giảm thiểu một khi đã tồn tại trong mã kernel. Các kỹ thuật gia cố đã xuất hiện trên kernel Android vài năm qua chủ yếu nhắm vào hỏng hóc mức slab và chiếm quyền điều khiển luồng thực thi.

Tác giả nhận xét rằng các lỗi kernel trong loạt bài này đều không hề tinh vi. Mỗi lỗi là một sai sót về vòng đời trang nhớ mà một buổi rà soát tập trung vào driver có thể phát hiện, và không driver nào có dấu hiệu được viết với giả định có kẻ gọi đối kháng.

Bài học rút ra là việc giới hạn quyền truy cập driver bằng một miền SELinux riêng chỉ hữu ích khi thực sự được áp dụng, và nó chỉ mạnh bằng chính bề mặt IPC phía người dùng dẫn vào miền đó. Các chuỗi khai thác trong nghiên cứu này cho thấy chỉ cần lỗi logic ở đó là đủ để vượt qua.

Ý nghĩa với người dùng Việt Nam

Với người dùng tại Việt Nam, nơi các dòng Galaxy S, Xiaomi và các máy Oppo, Realme có thị phần lớn, nghiên cứu này nhắc nhở rằng việc cập nhật bảo mật hàng tháng là cần thiết nhưng chưa đủ. Vì mã OEM nằm ngoài mã nguồn Android chung, các lỗ hổng kiểu này thường chỉ được vá qua bản cập nhật từ chính hãng, đôi khi chậm hơn so với các lỗ hổng kernel phổ thông.

Lời khuyên thực tế vẫn là: chỉ cài ứng dụng từ nguồn tin cậy, không bật nguồn không rõ ràng và cài bản cập nhật hệ thống ngay khi nhà sản xuất phát hành.

Loạt bài này sẽ tiếp tục với chi tiết kỹ thuật của từng chuỗi theo hãng. Tác giả cũng nhấn mạnh các lỗ hổng đã được báo cáo cho nhà sản xuất tương ứng.