Chuỗi khai thác 0-click cho Pixel 10

 (projectzero.google)
1 điểm bởi GN⁺ 2 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Chuỗi dành cho Pixel 10 sử dụng lỗ hổng Dolby 0-click từng tồn tại trên toàn bộ Android trước khi được vá làm bước đầu tiên, và bổ sung một đường leo thang đặc quyền cục bộ mới
  • Trình điều khiển BigWave trong chuỗi Pixel 9 không có trên Pixel 10 nên không thể chuyển nguyên sang, thay vào đó /dev/vpu trên Tensor G5 trở thành bề mặt tấn công
  • Trình điều khiển VPU đã trực tiếp phơi bày giao diện thanh ghi MMIO cho userspace, và chỉ sau 2 giờ kiểm tra đã phát hiện một lỗi mmap nghiêm trọng
  • remap_pfn_range ánh xạ chỉ dựa trên kích thước VMA thay vì kích thước thanh ghi, cho phép đọc và ghi vào .text và .data của kernel
  • Lỗ hổng được báo cáo vào ngày 24/11/2025 và được vá sau 71 ngày, cho thấy việc tăng cường bảo mật trình điều khiển Android vẫn còn cần thiết

Cấu thành chuỗi 0-click trên Pixel 10

  • Dựa trên chuỗi khai thác từng dùng hai exploit để đi từ ngữ cảnh 0-click tới quyền root Android trên Google Pixel 9, một chuỗi tương tự cũng được dựng cho Pixel 10
  • Lỗ hổng Dolby 0-click tồn tại trên diện rộng trong Android cho tới bản vá tháng 1/2026, và cũng được dùng làm bước đầu trong chuỗi nhắm vào Pixel 10
  • Trình điều khiển BigWave, vốn là bước leo thang đặc quyền cục bộ trên Pixel 9, không được tích hợp trong Pixel 10 nên không thể chuyển nguyên sang; thay vào đó trình điều khiển /dev/vpu trên Pixel 10 trở thành bề mặt tấn công mới

Cập nhật exploit Dolby

  • Việc điều chỉnh exploit hiện có cho CVE-2025-54957 sang Pixel 10 phần lớn chỉ là cập nhật các offset dựa trên thư viện Pixel 9 sang các offset tương ứng trong thư viện Pixel 10
  • Pixel 10 dùng RET PAC thay vì -fstack-protector, nên không thể ghi đè __stack_chk_fail
  • Sau nhiều lần thử, phương án được dùng là ghi đè mã khởi tạo dap_cpdp_init, vốn chỉ được gọi một lần khi khởi tạo bộ giải mã và không bị gọi lại
  • Exploit Dolby UDC đã cập nhật được công bố tại đây, và chỉ hoạt động trên các thiết bị chưa vá ở mức SPL tháng 12/2025 trở xuống

BigWave bị loại bỏ và VPU được thêm vào

  • Pixel 10 không có trình điều khiển BigWave nên không thể port bước leo thang đặc quyền cục bộ của chuỗi Pixel 9 hiện có
  • Trình điều khiển /dev/vpu, có thể được truy cập từ ngữ cảnh SELinux mediacodec, mới xuất hiện và được dùng để tương tác với silicon Chips&Media Wave677DV phục vụ tăng tốc giải mã video trên chip Tensor G5
  • Theo chú thích trong tệp C công khai, trình điều khiển này dường như được phát triển và duy trì bởi cùng nhóm đã tạo ra trình điều khiển BigWave
  • Kết quả kiểm tra trình điều khiển VPU trong 2 giờ cùng với Jann Horn đã phát hiện ra một lỗ hổng rất bất thường
  • Khác với trình điều khiển Linux upstream cho chip Chips&Media WAVE521C đời trước, trình điều khiển WAVE677DV trên Pixel không tích hợp với V4L2 (“Video for Linux API”)
  • Trình điều khiển Pixel trực tiếp phơi bày giao diện phần cứng của chip cho userspace, cho phép userspace ánh xạ giao diện thanh ghi MMIO của chip
  • Vai trò chính của trình điều khiển là thiết lập ánh xạ bộ nhớ thiết bị, quản lý nguồn điện, và hỗ trợ userspace chờ ngắt từ chip

Lỗ hổng kernel cốt lõi

  • Lỗi này là một lỗ hổng có cách khai thác cực kỳ đơn giản
  • Trình xử lý mmap có vấn đề là đoạn mã dùng để ánh xạ vùng thanh ghi MMIO của phần cứng VPU vào không gian địa chỉ ảo của userland
  • Lời gọi remap_pfn_range được thực hiện mà không bị giới hạn theo kích thước vùng thanh ghi, mà chỉ dựa trên kích thước VMA
  • Kẻ tấn công có thể chỉ định kích thước lớn hơn vùng thanh ghi trong lời gọi hệ thống mmap, từ đó ánh xạ từ địa chỉ vật lý của vùng thanh ghi VPU trở đi một lượng bộ nhớ vật lý tùy ý vào userland
  • Vì toàn bộ ảnh kernel nằm ở địa chỉ vật lý cao hơn vùng thanh ghi VPU, lỗi này cho phép truy cập và chỉnh sửa vùng .text và .data của kernel
  • Trên Pixel, kernel luôn nằm ở cùng một địa chỉ vật lý, nên offset giữa vùng nhớ VPU và kernel luôn là một giá trị đã biết
  • Nếu chỉ định độ dài VMA đủ lớn, không cần quét kernel trong bộ nhớ vật lý đã ánh xạ mà vẫn có thể xác định chính xác vị trí kernel dựa trên địa chỉ do mmap trả về
  • Chỉ cần 5 dòng mã để đạt được đọc/ghi tùy ý trong kernel với lỗ hổng này, và toàn bộ exploit được viết trong chưa tới một ngày
  • Có thể ghi đè một hàm kernel bất kỳ để giành thực thi mã trong kernel hoặc xây dựng primitive mong muốn

Xử lý bản vá

  • Lỗ hổng được báo cáo vào ngày 24/11/2025, và Android VRP đánh giá vấn đề này ở mức độ nghiêm trọng High
  • Lỗi BigWave từng được dùng để leo thang đặc quyền trên Pixel 9 có tác động bảo mật tương tự nhưng ban đầu bị đánh giá là Moderate, nên lần đánh giá này có thể xem là một sự cải thiện trong cách xử lý
  • Lỗ hổng được vá trong bản tin bảo mật Pixel tháng 2, 71 ngày sau báo cáo ban đầu
  • Đây được xem là lần đầu tiên một lỗi trình điều khiển Android được vá trong vòng 90 ngày kể từ khi được báo cáo lần đầu cho vendor
  • Quá trình xử lý này cho thấy phản ứng của Android trong việc phân loại và vá các lỗi cùng loại đã được cải thiện đáng kể

Ý nghĩa về bảo mật

  • Việc ứng phó với lỗ hổng VPU cho thấy pipeline phân loại của Android đã được cải thiện, với bản sửa lỗi ban đầu được đưa ra trong thời gian ngắn hơn nhiều so với vấn đề BigWave trước đó
  • Nỗ lực vá hiệu quả các lỗ hổng nghiêm trọng của Android giúp bảo vệ nhiều thiết bị Android hơn
  • Đồng thời, mã nguồn trình điều khiển Android vẫn cần được viết cẩn trọng hơn và phản ánh rõ ý thức bảo mật
  • Sau khi lỗi BigWave được báo cáo, người ta kỳ vọng các nhà phát triển liên quan sẽ rà soát những vấn đề bảo mật hiển nhiên ở các trình điều khiển khác; tuy nhiên 5 tháng sau, một lỗ hổng nghiêm trọng lộ ra ngay cả khi chỉ kiểm tra sơ bộ trong trình điều khiển VPU đã được phát hiện
  • Để bảo đảm an toàn cho hệ sinh thái Android, tăng cường bảo mật trình điều khiển vẫn là một ưu tiên quan trọng
  • Các vendor cần chủ động cải thiện thực hành phát triển phần mềm để lỗ hổng không đi tới tay người dùng cuối; đặc biệt với các sản phẩm quan trọng về bảo mật, ngay từ thời điểm phát hành chúng phải ở trạng thái có ít lỗ hổng một cách hợp lý
  • Các nhóm phần mềm cần áp dụng cách tiếp cận chủ động đối với bảo mật, kiểm tra mã và vá lỗ hổng

Bài viết liên quan

1 bình luận

 
GN⁺ 2 giờ trước
Ý kiến trên Hacker News

  • Lần theo liên kết về lỗi/khai thác của Pixel 9 thì thấy nội dung nói rằng vì các tính năng AI, hệ thống phải giải mã media trước khi người dùng mở tin nhắn, nên bề mặt tấn công 0-click đã tăng lên
    Cứ như thể đây là bài học lẽ ra chúng ta đã rút ra từ lâu rồi. Nghĩa là đừng đọc SMS và xử lý gì đó khi tôi còn chưa yêu cầu

    • Tôi không chắc chính xác bài học mà lẽ ra chúng ta phải học là gì
      Người dùng chọn điện thoại có tính năng nhắn tin phong phú. Trên iPhone là iMessage, rồi sau đó Android mới dần bắt kịp với RCS, và đây từng là một điểm bán hàng rất lớn
    • Chỉ như vậy thôi là chưa đủ. Hãy nghĩ đến một ứng dụng email không phân tích ảnh cho đến khi người dùng tương tác với thư; đến lúc họ nhấp vào và nhận ra có gì đó đáng ngờ thì một cỗ máy phức tạp đầy lỗi đã chạy rồi
      Điều cá nhân tôi thấy vô lý nhất là có lần tôi đánh dấu một thư cực kỳ đáng ngờ, gần như chắc chắn có tệp đính kèm độc hại, là spam trong một webmail của BigTech; vì đó không phải phishing nên không có lựa chọn khác, thế là hệ thống “tốt bụng” tự mở liên kết hủy đăng ký trên trình duyệt cục bộ của tôi mà không hỏi ý kiến. Thật khó tưởng tượng cần mức độ bất tài và rối loạn chức năng tổ chức đến đâu mới có thể viết, review, phê duyệt và triển khai một tính năng như vậy trong bối cảnh nhạy cảm về bảo mật và quyền riêng tư
    • Google sở hữu Android, nhưng Google không quan tâm đến người dùng. Khách hàng của họ là nhà xuất bản quảng cáo
      0-day cũng không quá quan trọng. Gần như chỉ còn iPhone là lựa chọn thay thế thực sự, còn Huawei thì chỉ khả dụng ở một số khu vực, nên họ chẳng có nhiều lý do để bận tâm. Chúng ta rất cần một OS điện thoại mới và một tầng phần cứng mới
    • Gần đây tôi nghe một bài trình bày về “AI Security”, và ý chính gần như là “chúng ta sẽ nuốt trọn mọi đầu vào đi vào và đi ra khỏi AI một cách vô phê phán, đó là vấn đề bảo mật, nhưng chẳng làm gì được nên cứ xử lý hậu quả thôi”
      Họ còn nói kiểu như “nếu tác nhân đe dọa cập nhật tài liệu nội bộ thì có thể tác động đến AI”, nhưng nếu tác nhân đe dọa đang cập nhật tài liệu thì hệ thống đã bị xâm nhập rồi. Đây không phải mức “phá hoại Wikipedia”
    • Bắt người dùng mở tin nhắn thực ra không phải rào cản quá cao
      Ở góc nhìn người dùng, việc phải cẩn thận với từng tin nhắn mình mở là điều khó chấp nhận. Chúng ta đã thử đẩy trách nhiệm đó sang người dùng với tệp đính kèm email, và nói kết quả là thảm họa thì cũng không sai. Tệp đính kèm độc hại có lẽ là con đường quan trọng nhất để phát tán mã độc

  • Cụm từ “đây là lần đầu tiên một lỗi driver Android được vá trong vòng 90 ngày kể từ khi nhà cung cấp lần đầu biết đến lỗ hổng sau khi được báo cáo, nên đặc biệt nhanh” khiến tôi có thiện cảm hơn với Google, nhưng đồng thời phần còn lại của hệ sinh thái Android lại hơi đáng sợ
    Tôi tự hỏi thời gian phản hồi của Apple sẽ như thế nào

    • Các nhà cung cấp Android vốn đã mang tiếng xấu về cập nhật từ rất lâu. Một phần lý do thường được nêu là các hãng điện thoại fork UI Android gốc để tạo khác biệt với nhau, cung cấp các tính năng riêng theo thương hiệu và những tầm nhìn UI có phần ảo tưởng
      Nhưng như vậy thì khi có bản cập nhật Android gốc, khối lượng công việc migrate sẽ trở nên khổng lồ
    • Tôi từng báo một lỗi bảo mật cho Apple. Chuyện đã vài năm rồi nhưng tôi nhớ là mất khoảng 6 tháng mới có bản vá
      Chúng tôi qua lại vài lần để xây dựng PoC ổn định hơn, và sau khi tôi gửi PoC tái hiện được 100% thì chắc khoảng 2 tháng sau là vá xong
    • Xét việc hiện tại 42% thiết bị Android chưa được vá [1], quyết định công bố nghiên cứu và khiến tất cả đều dễ bị tấn công là một điều khá đáng chú ý
      [1] https://gs.statcounter.com/android-version-market-share
      [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...
    • Nếu là thiết bị Android của các thương hiệu nổi tiếng thì có thể kỳ vọng vào cập nhật bảo mật OS, vì nhà cung cấp cấp một có thể tự build và push
      Nhưng cập nhật bảo mật cho driver và firmware thì khó nói chắc. Những bản cập nhật như vậy thường phải đến từ các nhà cung cấp ở tầng trên, mà họ có thể có hoặc không có ý chí sửa vấn đề. Các thương hiệu nhỏ thường bán thiết bị Android giá rẻ rồi hầu như không cập nhật gì cả

  • Hơi liên quan một chút, tôi tự hỏi liệu tỷ lệ exploit bị công khai gần đây có thực sự tăng lên không, hay chỉ là vì AI đang được chú ý như công cụ tấn công/phòng thủ bảo mật nên nó xuất hiện trên tin tức thường xuyên hơn
    Cứ như hai ngày lại có thứ gì đó mới xuất hiện trên Linux, Windows, mobile, hay các công cụ phổ biến mà ai cũng dùng

    • Nếu đọc kỹ phần 1 thì đoạn code có vấn đề được đưa vào vì tính năng AI, còn exploit là do con người tìm ra
      https://projectzero.google/2026/01/pixel-0-click-part-1.html
      Vậy nên việc dùng AI làm tăng số lỗi, rồi con người lại phải đi nhặt chúng ra
    • Cuối tuần trước tôi tự phân tích thử, và trong năm 2024 có khoảng 100 CVE được công bố mỗi ngày. Đến tháng 4 thì đã chạm khoảng 200 CVE mỗi ngày
      Nếu nhìn ngược về trước năm 2023, chu kỳ tăng gấp đôi của số CVE công khai là khoảng 4–4,5 năm, còn từ đó đến nay chỉ khoảng 2 năm. Rõ ràng là đã tăng rất mạnh
    • Theo những người quản lý lỗi bảo mật mã nguồn mở, số báo cáo đã tăng rất nhiều. Ban đầu phần lớn gần như là báo cáo chất lượng thấp hoặc giả, nhưng giờ thì số báo cáo thực sự hợp lệ cũng đã nhiều hơn hẳn
    • Chỉ là suy đoán thôi vì tôi không phải nhà nghiên cứu bảo mật, nhưng có vẻ AI vừa đóng vai trò chất xúc tác làm tăng bề mặt tấn công có thể khai thác với chất lượng thấp, vừa tăng tốc công việc của các nhà nghiên cứu bảo mật
      Tức là dùng đúng thì rất tuyệt, còn dùng sai thì cực kỳ tệ
    • Trong vài tuần gần đây tôi đã báo cho các nhà cung cấp công cụ phổ biến một số vấn đề khá nghiêm trọng, nhưng để được xác nhận thì khó hơn bình thường nhiều
      Tôi nghe nói các đội phản hồi đang quá tải vì làn sóng báo cáo đổ về

  • Tôi muốn ai đó xác nhận xem mình có đúng không. Tôi đã đưa đúng prompt dưới đây vào gpt 5.5 xhigh

    does this look right to you? don't do any searches or check memory, just think through first principles

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; }

    Không cần tìm kiếm web mà nó vẫn chỉ ra đúng vấn đề. Tôi muốn thử cách tổng quát hơn, kiểu đưa hẳn cả một mảng codebase vào prompt chứ không chỉ một hàm cụ thể. Có vẻ nó có tiềm năng để phát hiện exploit bảo mật. Nếu vậy thì tôi thắc mắc vì sao ngay từ đầu thứ này lại được phát hành. Tôi biết đây là ví dụ đồ chơi, nhưng muốn học thêm

    • Đây không phải bài kiểm tra công bằng. Prompt không nói trực tiếp là hãy tìm bug, nhưng vẫn dẫn mô hình theo hướng đó khá mạnh
      Về cơ bản nó giống với phản biện từng xuất hiện trong một thread nơi người ta khẳng định model hiện tại giỏi ngang mythos
    • Giai thoại cá nhân: tôi thử đưa fragnesia.c và bản vá sau đó nhằm sửa vấn đề vào, và dù nó không tìm ra lỗ hổng mới hoàn toàn, có vẻ nó đã tìm ra 2 cách mới để khai thác cùng một lỗi gốc
      Xét việc đây là kết quả do một kẻ ngốc như tôi chỉ với gói Claude subscription làm được thì cũng khá ấn tượng
    • Chỉ thế này thôi thì chưa thể kết luận đó có phải cách thực sự hữu ích để tìm lỗ hổng hay không, vì ta không biết sẽ có bao nhiêu false positive nếu chạy trên toàn bộ mã nguồn
      Nói cách khác, đây có thể là https://en.wikipedia.org/wiki/Base_rate_fallacy
    • Tôi thắc mắc làm sao bạn biết được rằng nó không tìm kiếm trên web
    • Tôi đã dán đoạn code vào claude Opus 4.7 không có truy cập Internet và chỉ yêu cầu nó giải thích hàm này làm gì, vậy mà trong lúc giải thích nó cũng chỉ ra bug. Tôi không bảo nó đi tìm bug

      Observations & Potential Issues
      A few things worth flagging:

      1. No bounds checking on the mapping size. Userspace controls vm_end - vm_start and vm->vm_pgoff. Here vm_pgoff is ignored entirely and the size is trusted blindly. If the VPU's register block is, say, 64KB but userspace requests a 1MB mapping, the driver will happily map 1MB of physical address space starting at core->paddr — potentially exposing whatever hardware happens to live at adjacent physical addresses. A defensive check would be:
        Nếu đã đến thời kỳ bot có thể quét mọi PR của mọi dự án mã nguồn mở ngay khi nó xuất hiện, thì chu kỳ phát hành 70 ngày sẽ nhanh chóng trở nên không đủ để ngăn chặn việc exploit bị sử dụng trên diện rộng

  • Đây là một báo cáo lỗi xuất sắc. Tôi hoàn toàn không phải chuyên gia kernel, cách đây hơn 10 năm chỉ đọc qua một chút thôi, mà vẫn có thể theo dõi và hiểu chuyện gì đang xảy ra
    Chính vì đây thực sự là một lỗi nghiêm trọng mà công sức để tìm ra nó lại có vẻ không quá lớn, nên tôi thấy lo về những rủi ro khác có thể đang ẩn bên dưới. Ngoài ra, gần đây nhiều vấn đề bảo mật được AI tìm ra, và báo cáo này khiến tôi nghĩ đến hai điều. Chuyên môn vẫn cực kỳ có giá trị, và càng ngách thì càng giá trị. Đồng thời vẫn còn rất nhiều ngách mà AI chưa thống trị được

  • Tôi không rõ jailbreak iPhone đã biến đi đâu. Đã khá lâu rồi tôi chẳng thấy gì cả, nên không biết đang xảy ra chuyện gì. Không rõ là tôi đã bỏ lỡ điều gì, hay thực sự là không còn gì khả thi nữa
    Dù Apple đã làm gì thì cũng khá đáng nể, nhưng theo xu hướng hiện tại tôi muốn biết đây chỉ là vấn đề thời gian hay thực sự đã có thay đổi nào đó

    • Tư thế bảo mật của Apple tốt hơn Android khá nhiều nhờ Lockdown Mode, memory tagging và secure allocator
      Có thể đọc một phần ở đây: https://security.apple.com/blog/memory-integrity-enforcement...
    • Ngày nay exploit có thể tồn tại qua lần khởi động lại gần như là bất khả thi. Và exploit đủ để jailbreak giờ cần cả một chuỗi exploit hoàn chỉnh, giá trị của nó rất cao và sẽ bị vá ngay khi bị công khai
      Vì vậy cảnh jailbreak iPhone như ngày xưa giờ gần như không thể nữa
    • Tôi luôn thấy khó chịu vì “jailbreak” không được kiểm chứng ở mức độ tương đương với các lỗ hổng phần mềm trên những nền tảng khác

  • Có bằng chứng nào cho thấy AI đã tác động đến việc kinh doanh của các công ty như NSO ra sao không? Tôi tò mò không biết nó khiến họ trở nên vô dụng hay lại cường hóa cực mạnh cho họ

    • Tôi không biết chi tiết, nhưng có vẻ AI đang làm thay đổi cuộc chơi rất nhiều và có thể một lượng lớn “vốn” dưới dạng 0-day đã bốc hơi
      Nếu đúng vậy thì đó là tin tốt cho tất cả mọi người ngoại trừ NSO và các công ty tương tự

  • Tôi từng gặp vấn đề tương tự. Cách giải quyết trông có vẻ hợp lý, nhưng tôi hoài nghi về mức cải thiện hiệu năng được tuyên bố

  • Các cải tiến V4L2 để hỗ trợ giải mã video bằng phần cứng đã chờ được merge từ lâu, và giờ có vẻ đã vào mainline kernel
    Có lẽ mọi người không muốn chờ lâu đến vậy

  • Tôi ngạc nhiên khi ngay cả Project Zero cũng phải báo lỗi cho Android qua kênh chính thức và phải đối mặt với phân loại mức độ nghiêm trọng của Android VRP
    Tôi cứ nghĩ họ chỉ cần đi bộ sang văn phòng Android rồi thuyết phục trực tiếp về tầm quan trọng của lỗi là được

    • Nếu họ thấy cách “bình thường” quá đau khổ, có lẽ điều tiếp theo Project Zero sẽ thử là sửa luôn chính quy trình đó
    • Điều đó dựa trên giả định rằng Android sẽ chịu lắng nghe lời Project Zero