Chuỗi khai thác 0-click hoàn chỉnh trên Google Pixel 10 được tiết lộ

Google Project Zero gần đây đã gây chú ý khi công bố chuỗi khai thác cho phép từ một bối cảnh zero-click (không cần tương tác của người dùng) leo thang lên quyền root trên Android chỉ với hai bước khai thác trên Google Pixel 9. Sau khi lỗ hổng Dolby được vá vào tháng 1/2026, nhóm nghiên cứu đã chuyển sự chú ý sang người kế nhiệm: Pixel 10, để xem liệu chuỗi khai thác tương tự có khả thi hay không.

Cập nhật khai thác lỗ hổng Dolby

Việc cập nhật khai thác cho lỗ hổng CVE-2025-54957 trên Pixel 10 diễn ra tương đối thuận lợi. Đa phần các thay đổi cần thiết liên quan đến việc cập nhật các offsets (địa chỉ bù) được tính toán cho phiên bản thư viện cụ thể trên Pixel 9 sang các offsets tương tự trong thư viện của Pixel 10.

Thách thức duy nhất nằm ở việc Pixel 10 sử dụng cơ chế RET PAC thay cho -fstack-protector. Điều này có nghĩa là hàm __stack_chk_fail không còn khả dụng để bị ghi đè bởi mã độc. Sau một quá trình thử nghiệm và sai sót, nhóm nghiên cứu đã sử dụng dap_cpdp_init — một đoạn mã khởi始化 có thể được ghi đè mà không gây ra các vấn đề về chức năng — làm giải pháp thay thế, vì nó chỉ được gọi một lần khi bộ giải mã được khởi tạo.

Khai thác Dolby UDC đã cập nhật hiện hoạt động trên các thiết bị chưa được vá bản vá bảo mật tháng 12/2025 hoặc cũ hơn.

Loại bỏ BigWave và sự xuất hiện của VPU

Việc chuyển đổi phần leo thang đặc quyền cục bộ của chuỗi khai thác sang Pixel 10 ban đầu không khả thi vì driver BigWave không còn được tích hợp trên thiết bị này. Tuy nhiên, một driver mới đã xuất hiện trong ngữ cảnh SELinux của mediacodec tại đường dẫn /dev/vpu.

Driver này được sử dụng để tương tác với phần cứng Chips&Media Wave677DV trên chip Tensor G5, nhằm mục đích tăng tốc giải mã video. Dựa trên các bình luận trong các tệp nguồn C mở, driver này được phát triển và duy trì bởi cùng một nhóm lập trình viên đã xây dựng driver BigWave. Khi làm việc cùng với Jann Horn, nhóm đã dành 2 giờ để kiểm tra driver VPU này và phát hiện một lỗ hổng đặc biệt nghiêm trọng.

Khác với driver Linux upstream cho WAVE521C (một chip Chips&Media cũ hơn), driver Pixel cho WAVE677DV không tích hợp với V4L2 (Video for Linux API). Thay vào đó, nó trực tiếp lộ diện giao diện phần cứng của chip ra không gian người dùng, bao gồm việc cho phép không gian người dùng ánh xạ giao diện thanh ghi MMIO của chip.

"Chén thánh" của các lỗ hổng Kernel

Lỗi cụ thể này đã thu hút sự chú ý của nhóm nghiên cứu vì tính đơn giản và dễ khai thác đến mức kinh ngạc:

static int vpu_mmap(struct file *fp, struct vm_area_struct *vm)
{
    unsigned long pfn;
    struct vpu_core *core =
        container_of(fp->f_inode->i_cdev, struct vpu_core, cdev);
    vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP);
    /* This is a CSRs mapping, use pgprot_device */
    vm->vm_page_prot = pgprot_device(vm->vm_page_prot);
    pfn = core->paddr >> PAGE_SHIFT;
    return remap_pfn_range(vm, vm->vm_start, pfn, vm->vm_end-vm->vm_start, vm->vm_page_prot) ? -EAGAIN : 0;
}

Trình xử lý mmap này có mục đích ánh xạ vùng thanh ghi MMIO của phần cứng VPU vào không gian địa chỉ ảo của người dùng — một vùng nằm trong một phạm vi địa chỉ bộ nhớ vật lý nhất định. Trong quá trình thực hiện, nó gọi hàm remap_pfn_range dựa hoàn toàn trên kích thước của VMA (Virtual Memory Area) mà không bị giới hạn bởi kích thước thực tế của vùng thanh ghi này.

Điều này có nghĩa là bằng cách chỉ định kích thước lớn hơn vùng thanh ghi trong một syscall mmap, người gọi có thể ánh xạ bất kỳ lượng bộ nhớ vật lý nào mong muốn vào không gian người dùng, bắt đầu từ địa chỉ vật lý của vùng thanh ghi VPU. Toàn bộ hình ảnh kernel (bao gồm các vùng .text và .data) nằm ở địa chỉ vật lý cao hơn vùng nhớ VPU, do đó có thể được truy cập và sửa đổi bởi không gian người dùng thông qua lỗi này.

Tại thời điểm này, kẻ tấn công có thể đơn giản ghi đè bất kỳ hàm kernel nào để đạt được quyền thực thi mã kernel — hoặc thậm chí là bất kỳ nguyên thủy khai thác nào mong muốn. Việc này trở nên dễ dàng hơn nữa bởi việc kernel luôn nằm tại một địa chỉ vật lý cố định trên Pixel, do đó khoảng cách giữa vùng nhớ VPU và kernel luôn là một giá trị đã biết. Vì vậy, thậm chí không cần phải quét tìm kernel trong bộ nhớ vật lý đã ánh xạ — bạn chỉ cần biết chính xác nó nằm ở đâu tương đối với địa chỉ được mmap trả về, miễn là bạn đặt độ dài VMA đủ lớn.

Việc đạt được quyền đọc-ghi tùy ý trên kernel với lỗ hổng này chỉ cần 5 dòng mã, và việc viết một khai thác hoàn chỉnh cho vấn đề này mất ít hơn một ngày công sức.

Quy trình vá lỗi

Lỗi này được báo cáo vào ngày 24 tháng 11 năm 2025 và Chương trình Phần thưởng Bảo mật Android (Android VRP) đã đánh giá vấn đề này ở mức độ nghiêm trọng Cao (High severity). Đây là một sự cải thiện tích cực, vì lỗ hổng BigWave mà nhóm sử dụng để leo thang đặc quyền trên Pixel 9 (vốn có tác động bảo mật tương tự) trước đây từng được đánh giá là mức độ Trung bình (Moderate severity). Điều này đại diện cho một thay đổi có ý nghĩa và tích cực trong cách xử lý và phân loại các loại lỗi này.

Lỗ hổng đã được vá sau 71 ngày kể từ khi báo cáo ban đầu, trong bản tin bảo mật tháng 2 của Pixel. Đây là tốc độ đáng kể nhanh chóng, xem xét đây là lần đầu tiên một lỗi driver Android mà tác giả báo cáo được vá trong vòng 90 ngày kể từ khi nhà sản xuất biết về lỗ hổng.

Kết luận

Nghiên cứu này mang lại cả những mặt tích cực và tiêu cực. Một mục tiêu chính của Project Zero là thúc đẩy những cải thiện mang tính hệ thống vượt ra ngoài việc sửa lỗi cá nhân, ảnh hưởng đến quy trình phát triển tốt hơn và cơ sở mã resilient hơn, dẫn đến cải thiện bảo mật cho người dùng cuối. Cách xử lý lỗ hổng VPU này chứng minh sự tiến bộ rõ ràng trong quy trình phân loại của Android, vì lỗi này đã được khắc phục trong một khoảng thời gian ngắn hơn nhiều so với các vấn đề BigWave trước đây. Nỗ lực của Android trong việc đảm bảo các lỗ hổng nghiêm trọng được vá hiệu quả sẽ giúp bảo vệ nhiều thiết bị Android hơn.

Tuy nhiên, trường hợp này cũng nhấn mạnh nhu cầu liên tục cần có mã hóa mạnh mẽ và nhận thức bảo mật hơn trong các driver Android. Khi tác giả báo cáo các lỗi trong BigWave, họ hy vọng sẽ thúc đẩy các nhà phát triển đánh giá các driver khác của họ để tìm các vấn đề bảo mật rõ ràng, nhưng 5 tháng sau, họ vẫn tìm thấy một lỗ hổng nghiêm trọng và cực kỳ nông trong driver VPU của họ, điều này có thể nhận thấy ngay lập tức ngay cả khi chỉ kiểm tra sơ sơ cơ sở mã. Việc tăng cường bảo mật driver vẫn là một ưu tiên quan trọng để đảm bảo một hệ sinh thái Android an toàn, và chúng tôi tiếp tục khuyến khích mạnh mẽ các nhà cung cấp cải thiện các thực hành phát triển phần mềm một cách chủ động để ngăn chặn các loại lỗ hổng này tiếp cận người dùng cuối.

Các báo cáo bảo mật thường phát hiện ra các vấn đề phức tạp bị các nhóm sản phẩm bỏ sót, nhưng điều quan trọng là các nhà cung cấp phần mềm phải thực hiện các bước cần thiết để đảm bảo các sản phẩm phần mềm, đặc biệt là những sản phẩm quan trọng về bảo mật, được ra mắt ở trạng thái tương đối không có lỗ hổng và rằng các nhóm phần mềm tiếp cận bảo mật phần mềm, kiểm tra mã và vá lỗi một cách chủ động.