Khắc phục lỗ hổng CVE-2024-0517 trong Google Chrome

CVE-2024-0517 là lỗ hổng ghi ngoài giới hạn trong công cụ JavaScript V8 của Google Chrome trước phiên bản 120.0.6099.224, cho phép kẻ tấn công từ xa khai thác lỗi heap thông qua trang HTML được tạo thủ công. Lỗ hổng này lần đầu tiên được báo cáo bởi Toan (Suto) Pham của Qrious Secure . 

Kẻ tấn công có thể lưu trữ một trang web chứa trang HTML được tạo thủ công và lừa người dùng truy cập trang web đó thông qua email lừa đảo hoặc mạng xã hội. Khi người dùng truy cập trang web bằng phiên bản Google Chrome dễ bị tấn công, mã độc được nhúng sẽ thực thi các lệnh tùy ý. 

Kẻ tấn công có thể lưu trữ một trang web chứa trang HTML được tạo thủ công và lừa người dùng truy cập trang web đó thông qua email lừa đảo hoặc mạng xã hội. Khi người dùng truy cập trang web bằng phiên bản Google Chrome dễ bị tấn công, mã độc được nhúng sẽ thực thi các lệnh tùy ý. 

Maglev, trình biên dịch tối ưu hóa trong V8, tăng cường thực thi mã và phân bổ bộ nhớ. Maglev chỉ chạy khi mã được thực thi thường xuyên và được đánh dấu là "nóng", cho biết nhu cầu thực thi nhanh hơn thông qua biên dịch thay vì diễn giải từng dòng chậm hơn. 

Thông thường, việc phân bổ xảy ra ở các vùng bộ nhớ không liền kề, dẫn đến việc sử dụng bộ nhớ thưa thớt và không hiệu quả. Để giải quyết vấn đề này, V8 sử dụng một kỹ thuật gọi là phân bổ gấp, phân bổ nhiều biến liên tục và đồng thời. Maglev cũng tối ưu hóa việc phân bổ bằng cách sử dụng phân bổ gấp trong quá trình thực hiện. 

Để dọn dẹp các vùng bộ nhớ chưa sử dụng, V8 sử dụng kỹ thuật thu gom rác theo thế hệ (GC), chia bộ nhớ thành hai không gian: thế hệ trẻ và thế hệ cũ. Ngoài ra, có hai trình thu gom rác: trình thu gom rác phụ, có trách nhiệm dọn dẹp không gian trẻ và trình thu gom rác chính, xử lý việc dọn dẹp không gian cũ. Thế hệ trẻ là vùng bộ nhớ nơi các đối tượng mới được tạo ban đầu được phân bổ và thế hệ cũ là vùng bộ nhớ nơi các đối tượng tồn tại lâu dài được lưu trữ. Các đối tượng đã tồn tại qua nhiều chu kỳ GC phụ trong thế hệ trẻ cuối cùng sẽ được thăng cấp lên thế hệ cũ. 

Lỗ hổng này phát sinh khi một đối tượng được tạo từ một lớp kế thừa từ một lớp cơ sở mà không có hàm tạo được xác định rõ ràng (hàm tạo mặc định cơ sở) và một đối tượng khác được tạo sau đó. Do phân bổ gấp, việc phân bổ đối tượng đầu tiên có thể được theo sau bởi việc phân bổ đối tượng thứ hai. Nếu một sự kiện như thu gom rác xảy ra giữa hai lần phân bổ này, lỗ hổng nhầm lẫn kiểu có thể phát sinh.

OPSWAT Các nghiên cứu sinh đã tiến hành phân tích chi tiết quy trình làm việc V8 trong quá trình phân bổ và xác định rằng các chức năng sau đây được gọi trong quá trình này: 

Để khai thác lỗ hổng này, OPSWAT Các nghiên cứu sinh đã tạo ra các phiên bản WebAssembly chứa shellcode và cố gắng kích hoạt nhầm lẫn kiểu bằng GC để kiểm soát bộ nhớ và thực thi shellcode: 

Trong quá trình khởi tạo, trước tiên chúng ta định nghĩa một mảng (_arrayObject) chứa các đối tượng rỗng. Tiếp theo, chúng ta xây dựng một thể hiện của lớp con cũng như một trình thu gom rác kích hoạt. Cuối cùng, chúng ta định nghĩa một mảng khác với số dấu phẩy động, có tên là _arrayDouble. 

Sau khi kích hoạt nhầm lẫn kiểu thành công, việc thực thi shellcode đòi hỏi phải đọc bộ nhớ và ghi đè bộ nhớ tại một địa chỉ được kiểm soát. Để thực hiện việc này, chúng tôi đã tạo các nguyên hàm đọc và ghi. Các nguyên hàm khai thác sẽ tận dụng siêu dữ liệu trong các đối tượng để cung cấp cho chúng tôi các vùng bộ nhớ đọc/ghi tùy ý và sử dụng vùng đó để chạy mã tùy ý. 

Tiếp theo, chúng tôi tạo hai phiên bản WebAssembly: một để lưu trữ shellcode và một để kích hoạt shellcode. Để tránh ghi trực tiếp shellcode vào bộ nhớ của phiên bản WebAssembly thông qua các nguyên hàm đọc và ghi, chúng tôi định nghĩa một số giá trị hằng số dấu phẩy động trong phiên bản WebAssembly. 

Sử dụng các nguyên hàm đọc và ghi; chúng tôi điều chỉnh con trỏ bảng nhảy của phiên bản WebAssembly thứ hai để bỏ qua một số byte của mã đã biên dịch của các hằng số trong phiên bản WebAssembly đầu tiên để các hằng số dấu phẩy động sẽ được diễn giải thành shellcode theo ý định của chúng tôi:

Cuối cùng, sau khi kích hoạt nhầm lẫn kiểu và sử dụng các nguyên hàm đọc/ghi để kiểm soát các con trỏ bảng nhảy của các thể hiện WebAssembly, chúng tôi đã gọi hàm được xuất của thể hiện WebAssembly thứ hai, hàm này khiến cho shellcode trong thể hiện WebAssembly đầu tiên được thực thi. 

Mã lệnh shellcode mà chúng tôi đang sử dụng được thiết kế để chấm dứt mọi tiến trình trên máy Linux, bằng lệnh sau: 

Để mô phỏng việc khai thác này trong một kịch bản thực tế, OPSWAT Các nghiên cứu sinh đã tạo ra một trang HTML có chủ đích. 

MetaDefender Endpoint™ đã được sử dụng để chủ động giảm thiểu CVE này bằng cách tận dụng khả năng "Ứng dụng dễ bị tấn công" của nó. Giải pháp này xác định và hiển thị hiệu quả tất cả các CVE liên quan cho các ứng dụng Google Chrome trong môi trường điểm cuối. Để vô hiệu hóa mối đe dọa, người dùng có thể nhanh chóng gỡ cài đặt Chrome hoặc áp dụng bản vá bảo mật mới nhất. Bằng cách triển khai bất kỳ biện pháp đối phó nào, CVE sẽ được chứa hoàn toàn, giúp giảm đáng kể nguy cơ tấn công mạng thành công vào điểm cuối.

Khám phá lý do tại sao các tổ chức, cơ quan và thực thể trên toàn thế giới tin tưởng MetaDefender Endpoint để bảo vệ các điểm cuối quan trọng. Hãy trao đổi với chuyên gia ngay hôm nay để tìm hiểu thêm và tự mình xem qua bản demo miễn phí.