# RCE trong Chrome: Hacker chỉ cần bạn mở trang web là đủ!

Gần đây một lỗ hổng nguy hiểm đã được phát hiện trong **JavaScript V8 của Google Chrome** cho phép những kẻ tấn công thực thi mã từ xa một cách tùy ý trên hệ thống mục tiêu. Lỗ hổng này bắt nguồn từ một **sai sót trong canonicalization kiểu của WebAssembly (Wasm)**, đặc biệt trong hàm `CanonicalEquality::EqualValueType()` – tức là trong việc so sánh và “chuẩn hóa” các kiểu dữ liệu của Wasm.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760068878143/290e012d-7ed2-44d6-881c-0cc4e6b936a4.png align="center")

## **Tác động chính**

* Thực thi mã từ xa
    
* Vượt qua sandbox của trình duyệt
    
* Tự động hóa và khai thác hàng loạt
    
* Ảnh hưởng đến người dùng và doanh nghiệp
    

## **Chi tiết khai thác**

Như đã đề cập thì lỗ hổng này tồn tại do một lỗi logic trong kiểm tra kiểu giữa `ref t` và `ref null t`. Bên cạnh đó thì việc kết hợp với **thiếu kiểm tra hash chính xác** khi canonicalize recursive types trong Wasm cũng dẫn đến tồn tại lỗ hổng này từ đó kẻ tấn công có thể RCE thành công vào hệ thống của bạn. Vấn đề này cũng dẫn đến nguy cơ tồn tại hai lỗ zero-day từng bị khai thác trước đó: **CVE-2024-12381 và CVE-2024-12692**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760067009796/09873730-fe12-4954-8736-516afc8cda5c.png align="center")

Trước tiên kẻ tấn công sẽ thực hiện tạo một vùng bộ nhớ có thể đọc và ghi vượt giới hạn (OOB). Cụ thể trong WebAssembly `CanonicalEqualityEqualValueType`, không phân biệt đúng giữa `ref t` và `ref null t` trong recursive type group. Khi đó nếu attacker cung cấp các recursive type cấu trúc tương tự nhưng chỉ khác về nullability, hệ thống sẽ hash ra cùng một giá trị (do MurmurHash không tính nullability).

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760078140390/3247673b-77b2-4b85-9f6e-d61194b15386.png align="center")

Tiếp tục sang giai đoạn tạo OOB và chiếm quyền điều khiển. Mục tiêu của kẻ tấn công là lợi dụng type confusion để biến một object `ref null t` thành `ref t` điều này sẽ gây lỗi truy cập và từ đó cấp quyền đọc hoặc ghi tự do trên `ArrayBuffer`.

Chi tiết với chiến dịch này, kẻ tấn công sẽ tạo ra một object giả mạo trong bộ nhớ và ép WebAssembly thực thi hàm với object sai kiểu nhưng không bị crash.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760078311036/fa196ab4-e221-451d-9ce5-7f74fa8c1e7a.png align="center")

Bước tiếp theo cũng như quan trọng nhất là thực hiện “**Bypass Sandbox (escape V8 sandbox)”. Kẻ tấn công sẽ** lợi dụng cơ chế `JSPI` (JavaScript Promise Integration) và dùng Promise stack chuyển đổi frame, từ đó tạo các frame “rỗng” (suspended) nhằm thoát khỏi sandbox của V8 để thực thi mã native. Đương nhiên sau khi đã Bypass thành công thì **VirtualProtect** sẽ được gọi nhằm thực thi shellcode.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1760078933012/a1e4f421-8c42-4551-8064-ca55e86c8613.png align="center")

Cuối cùng tất nhiên là thực thi shellcode. Kẻ tấn công sẽ gọi `VirtualProtect` để set quyền `RWX` (read-write-execute). Sau đó chúng sẽ coppy các đoạn mã thực thi hay payload vào vùng nhớ đó và chạy một tiến trình `calc.exe` để thực thi mã tùy ý trên hệ thống mục tiêu.

## **Kết luận**

Lỗ hổng **RCE không qua sandbox trong Google Chrome thông qua** `CanonicalEquality::EqualValueType()` là một minh chứng rõ ràng cho thấy những **lỗi logic phức tạp trong xử lý kiểu dữ liệu (type canonicalization)** có thể dẫn đến **thực thi mã từ xa cấp độ hệ thống**, đặc biệt khi được kết hợp với **kỹ thuật by pass sandbox tinh vi** như **JSPI stack switching**.

Người dùng và tổ chức cần có **chiến lược phản ứng nhanh**, đặc biệt là trong môi trường sử dụng WebAssembly hoặc sandbox. Lỗ hổng lần này không chỉ là một vấn đề kỹ thuật, mà còn là lời cảnh báo về cách những chi tiết nhỏ trong logic hệ thống có thể bị khai thác để phá vỡ những rào cản bảo mật lớn nhất.

## **Khuyến nghị**

1. **Cập nhật Google Chrome ngay lập tức**
    
    * Kiểm tra và đảm bảo trình duyệt đang ở **phiên bản mới nhất** (tối thiểu trên M137 với bản vá chính thức nếu có).
        
    * Truy cập: `chrome://settings/help` để kiểm tra và cập nhật thủ công.
        
2. **Tuyệt đối không sử dụng Chrome với tùy chọn** `--no-sandbox`
    
    * Một số người dùng (nhất là dev hoặc trong môi trường Docker) khởi chạy Chrome với flag `--no-sandbox` để tránh lỗi. Điều này **cực kỳ nguy hiểm** khi có lỗ hổng RCE.
        
    * Gỡ bỏ flag này khỏi mọi cấu hình (ví dụ: script CI/CD, Dockerfile, shortcut…).
        
3. **Tắt JavaScript hoặc WebAssembly khi không cần thiết**
    
    * Nếu đang duyệt web trong môi trường rủi ro cao (bug bounty, darknet, v.v), cân nhắc dùng tiện ích:
        
        * **NoScript** hoặc **uBlock Origin** để chặn các script / WebAssembly không đáng tin.
            
    * Có thể cấu hình để chặn Wasm qua `chrome://flags`:
        
        * Tìm `"WebAssembly"` và tắt thủ công các mục như `"WebAssembly Garbage Collection"` nếu cần.
            
4. **Cấu hình hệ thống giám sát các hành vi nghi ngờ**
    
    * Theo dõi các hoạt động bất thường như:
        
        * Truy cập địa chỉ vùng nhớ bất hợp lý từ Chrome.
            
        * Tăng bất thường về tài nguyên khi tải trang.
            
        * Dữ liệu WebAssembly bất thường trong traffic (qua proxy/nghiệp vụ IDS).
            
    * **Không mở link lạ**, đặc biệt là các link HTML gửi qua email/chat
        

## **Tham khảo**

1. [https://cybersecuritynews.com/google-chrome-rce-vulnerability/#google\_vignette](https://cybersecuritynews.com/google-chrome-rce-vulnerability/#google_vignette)
    
2. [Google Chrome RCE (no sandbox) via CanonicalEquality::EqualValueType() - SSD Secure Disclosure](https://ssd-disclosure.com/google-chrome-rce-no-sandbox-via-canonicalequalityequalvaluetype/)