Phát hiện lỗ hổng trong Apache OpenOffice có thể bị tấn công bởi tài liệu độc hại

[vpn]

Apache OpenOffice (AOO) dễ dàng bị tấn công bởi lỗ hổng thực thi mã từ xa, bất chấp mã nguồn của ứng dụng này đã được vá. Tuy nhiên, bản vá này chỉ mới được cung cấp dưới dạng phần mềm beta và đang chờ bản phát hành chính thức.

Điều đó có nghĩa là hàng trăm triệu người dùng đang chạy bộ phần mềm office mã nguồn mở, cho dù đã cập nhật lần cuối vào tháng 5, vẫn có thể có các phiên bản chứa lỗ hổng dễ bị tấn công.

Vào thứ bảy vừa qua, nhà nghiên cứu bảo mật Eugene Lim đã tiết lộ chi tiết về lỗ hổng an ninh (CVE-2021-33035) tại hội nghị trực tuyến Hacktivity của HackerOne sau ngày công bố bản.

Lim (SpaceRacoon) là một nhà nghiên cứu lỗ hổng tại Tập đoàn An ninh mạng GovTech Singapore, cho biết: "CVE-2021-33035 là sự cố tràn bộ đệm (buffer overflow) bởi một tệp .dbf ghi đè con trỏ trả về (return pointer) với việc bypass qua cơ chế DEP (ngăn chặn thực thi dữ liệu) và ASLR (ngẫu nhiên hóa không gian địa chỉ) để có thể thực hiện các lệnh tùy ý của kẻ tấn công". Vì vậy, một tập tin độc hại được mở bởi phần mềm OpenOffice có thể hoàn toàn thực thi mã độc trên máy tính nạn nhân.

Lim đã phát hiện ra lỗ hổng sau khi kiểm tra định dạng file .dbf. Những gì ông tìm thấy là định dạng file .dbf có thể sử dụng một trong hai giá trị trong header của nó là -fieldLength hoặc fieldType- để xác định kích thước bộ đệm (buffer) của bản ghi cơ sở dữ liệu. Vì vậy, có thể cấp phát một bộ đệm bằng cách sử dụng nó và sử dụng bộ đệm kia để đặt kích thước của hoạt động sao chép vào bộ đệm đó, dẫn đến tràn bộ đệm.

Đoạn code phân tích cú pháp của tệp .bdf trong OpenOffice:

else if ( DataType::INTEGER == nType )
 {
          sal_Int32 nValue = 0;
          memcpy(&nValue, pData, nLen);
         *(_rRow->get())[i] = nValue;
 }

Lim giải thích trong một bài đăng trên blog: “Ở đây, chúng ta có thể thấy một bộ đệm nValue có kích thước sal_Int32(4 byte) được khởi tạo cho một kiểu INTEGER. Tiếp theo, sao chép một bộ đệm có kích thước nLen - là giá trị do kẻ tấn công kiểm soát - vào nValue mà không xác nhận nLen nhỏ hơn hoặc bằng 4".

Sửa đổi trình tạo payload trước đó thành số nguyên fieldType(I), anh ấy đã tăng kích thước của fieldLength lên lớn hơn sal_Int32 và có thể khởi chạy một cuộc tấn công PoC bao gồm việc mở tệp trong OpenOffice Calc và gây ra crash.

Để khai thác triệt để điều này và đạt được khả năng thực thi code đáng tin cậy, ít nhất trên Windows, Lim đã phải bỏ qua DEP và ASLR. Để làm như vậy, anh ấy đã tìm kiếm các mô-đun đã import chưa được biên dịch với các biện pháp bảo vệ đó và tìm được libxml2, một thư viện phần mềm để phân tích cú pháp các tài liệu XML.

Vì vậy, Lim có thể sử dụng thư viện này như một điểm khởi đầu cho một chuỗi ROP (Return-Oriented Programming - lập trình hướng trở lại), để cuối cùng vượt qua cơ chế DEP.

ROP, như Lim giải thích, là một kỹ thuật liên kết các đoạn mã lại với nhau nằm trong bộ nhớ của ứng dụng - giống như cắt các chữ cái từ báo và tạp chí để viết ra một câu, nhưng trong trường hợp này, nó sắp xếp các instruction của phần mềm để thực thi - cho đến khi mục tiêu cụ thể đã được hoàn thành. Vì con trỏ ghi đè mà anh ta lấy được chỉ cung cấp khoảng 256 byte để hoạt động, chuỗi ROP của anh ta đã trở thành GetModuleHandleA và sau đó là GetProcAddress để định vị mã WinExec và thực thi các lệnh shell của riêng anh ta. Tại thời điểm này, anh ta có thể chạy bất cứ thứ gì anh ta muốn trên máy của nạn nhân.

Lim trong bài đăng của mình nói rằng anh ấy tự hỏi tại sao điều này không được phát hiện và nhận thấy rằng quá trình quét bảo mật tự động LGTM của GitHub cho các dự án mã nguồn mở có gắn thẻ (tag) Apache OpenOffice cho Python và JavaScript nhưng không phải C++.

"Duyệt qua các tệp trên LGTM, nhận thấy rằng không có tệp C++ nào được include. Điều này chứng tỏ tầm quan trọng của các công cụ phân tích tĩnh tự động kiểm tra tính sanity; nếu các công cụ của bạn không biết đoạn code tồn tại, nó không thể tìm thấy các lỗ hổng đó".

Anh ấy cũng cho biết rằng lỗ hổng cũng ảnh hưởng đến Scalabium dBase Viewer (CVE-2021–35297) và vì dự án đó do một nhà phát triển duy nhất điều hành nên việc sửa lỗi diễn ra nhanh chóng. Với Apache OpenOffice, công ty đã phải vật lộn để duy trì trong những năm gần đây, tiết lộ ban đầu xảy ra vào ngày 4 tháng 5 và nếu may mắn, bản sửa lỗi sẽ được hoàn tất trước cuối tháng 9.

Dave Fisher, đại diện cho Apache OpenOffice PMC, cho biết: "Chúng tôi cố gắng triển khai bản phát hành cho Apache OpenOffice 4.1.11 trong tháng, hy vọng sớm hơn và xuất bản CVE-2021-33035 trước khi phát hành."

Đối với những người không muốn chờ đợi, có thể tìm thấy trình cài đặt beta tại đây và mã nguồn đã được vá.

Nguồn: theregister.com​