Phân tích mã lỗi CVE-2015-0311 trong Adobe Flash Player

[firey522]

Cuối tháng 1 năm 2015, Adobe đã đưa ra bản cập nhật bảo mật APSA15-01 cho sản phẩm Flash Player của mình trong đó đã bao gồm lỗ hổng use-after-free nghiêm trọng ảnh hưởng tới phiên bản Adobe Flash Player 16.0.0.287 và các phiên bản trước đó. Lỗ hổng này còn được biết tới như CVE-2015-0311 cho phép những kẻ tấn công có thể thực thi các đoạn mã tùy ý trên các thiết bị chứa lỗ hổng bằng cách dụ người dùng vào trang web có chứa một file SWF Flash đã được chỉnh sửa.

Lỗ hổng này được phát hiện lần đầu tiên như một lỗ hổng zero-day và được sử dụng trong bộ công cụ khai thác Angler Exploit Kit.

Nguyên nhân của lỗ hổng

Trong khi cố gắng giải nén dữ liệu trong một ByteArray đã được nén lại trước đó bằng zlib. Hoạt động này được xử lý trong phương thức “ByteArray:: UncompressViaZlibVarriant”. Phương thức này sử dụng lớp ByteArray::Grower để thực hiện tự động tăng kích thước vùng đệm chứa dữ liệu được giải nén.

Sau khi thực hiện thành công việc tăng thêm bộ đệm đích này, phương thức hủy của lớp Grower sẽ thông báo cho tất cả các thành phần sử dụng ByteArray đã nói ở trên để chúng có thể sử dụng bộ đệm mới được tăng cường. Một thành phần nhận được thông báo này là thuộc tính “ApplicationDomain.currentDomaint.domainMemory"

Vấn đề xảy ra nếu hàm inflate() của thư viện zlib không thể thực hiện khi dữ liệu trong ByteArray không phải là dữ liệu đã được nén với zlib. Trong trường hợp đó phương thức “UncompressViaZlibVariant” sẽ giải phóng vùng đệm tăng thêm và phục hồi lại những dữ liệu nguyên gốc trong ByteArray. Tuy nhiên nó không báo lại cho các thành phần khác và ở đây là “domainMemory” việc bộ đệm mới đã bị giải phóng và vùng nhớ này vẫn có thể được tiếp tục sử dụng.

Để hiểu rõ hơn về lỗ hổng này chúng ta hãy cùng nhìn sâu hơn vào mã nguồn ActionScript Vitual Machine của Adobe Flash. (https://github.com/adobe-flash/avmplus).

Khi bắt đầu giải nén dữ liệu trong ByteArray, hàm “ByteArray::Uncompress” (core/ByteArrayGlue.cpp) sẽ kiểm tra xem dữ liệu được nén theo hình thức nào và lựa chọn kiểu giải nén cho phù hợp:

​

Hàm ByteArray::UncompressViaZlibVariant() khi được sử dụng sẽ gọi tới hàm “inflate()” của thư viện zlib trong một vòng lặp nhằm giải nén dữ liệu trong ByteArray

​

Ở đây phương thức Write được gọi để sao chép phần dữ liệu được giải nén vào bộ đệm đích. Phương thức Write cũng sẽ khởi tạo một thực thể của lớp “Grower” và gọi tới phương thức “EnsureWritableCapacity()” để tăng kích thước vùng đệm đích. Sau khi hàm Write thực hiện xong, thực thể này của lớp “Grower” cũng sẽ được hủy bỏ.

​

Khi hàm hủy của lớp Grower đươc thực thi, nếu vùng đệm mới được tạo ra hàm NotifySubscribers sẽ thực hiện thông báo cho tất cả các thành phần liên quan biết để sử dụng vùng đệm này.

Cuối cùng hàm “DomainEnv::notifyGlobalMemoryChanged()” sẽ cập nhật lại địa chỉ và kích thước vùng nhớ theo thông tin nhận được từ NotifySubscribers().

Sau khi đã thực hiện tất cả các bước trên sẽ kết thúc một vòng lặp của hàm “UncompressViaZlibVariant()” và tiếp tục vòng lặp. Trong khi thực hiện, nếu một trong số các hàm “inflate()” trả về kết quả khác 0, vòng lặp sẽ kêt thúc và kiểm tra xem dữ liệu đã được giản nén hoàn tòan hay chưa. Nếu kết quả có phát sinh lỗi vùng đệm mới tạo ra sẽ được giải phóng và vùng dữ liệu ban đầu sẽ được khôi phục

​

Tuy nhiên không giống khi tạo ra, khi vùng đệm này được giải phóng không hề có một thông tin nào được báo tới các thành phần sử dụng nó.

“ApplicationDomain.currentDomain.domainMemory” sẽ tiếp tục giữ liên kết với vùng nhớ này mặc dù nó đã được giải phóng dẫn tới một lỗi use-after-free

Trên đây là ý tưởng chính của mã lỗi CVE-2015-0311, ở phần tiếp theo của bài viết chúng ta sẽ thử nhiệm việc khai thác mã lỗi này.