AcademySoftwareFoundation OpenEXR: SampleCountChannel đọc vượt giới hạn với dataWindow có gốc khác 0

OpenEXR là triển khai tham chiếu và đặc tả cho định dạng tệp ảnh EXR, được sử dụng rộng rãi trong ngành công nghiệp điện ảnh. Trong các phiên bản đến 3.2.10, từ 3.3.0 đến 3.3.12 và từ 3.4.0 đến 3.4.13, thư viện OpenEXRUtil trả về một con trỏ nằm ngoài giới hạn từ API SampleCountChannel::row() khi một ảnh deep có gốc dataWindow khác 0. Bộ truy cập row() được tài liệu hóa là 0-based và tính địa chỉ từ một base nội bộ được offset cho tọa độ pixel tuyệt đối, vì vậy hai mô hình tọa độ xung đột bất cứ khi nào dataWindow.min khác 0. Đối với ảnh deep có data window với gốc dọc âm lớn, row(0) trỏ xa ra ngoài buffer sample-count đã được cấp phát. Một ứng dụng mở tệp deep EXR do kẻ tấn công kiểm soát và truy cập sample counts thông qua row() sẽ thực hiện một thao tác đọc ngoài giới hạn, có thể làm tiến trình crash hoặc, trong một bố cục heap được kiểm soát, trả về bộ nhớ heap liền kề dưới dạng các giá trị sample-count. Vấn đề này được khắc phục trong các phiên bản 3.2.11, 3.3.13 và 3.4.14.

• AcademySoftwareFoundation openexr 2.x, 3.0.x và 3.1.x: bị ảnh hưởng theo advisory của dự án.
• Nhánh 3.2: các bản từ 3.2.0 đến 3.2.10 bị ảnh hưởng; bản sửa là 3.2.11.
• Nhánh 3.3: các bản từ 3.3.0 đến 3.3.12 bị ảnh hưởng; bản sửa là 3.3.13.
• Nhánh 3.4: các bản từ 3.4.0 đến 3.4.13 bị ảnh hưởng; bản sửa là 3.4.14.
• Trạng thái của các nhánh không được liệt kê rõ trong các nguồn đã kiểm tra, bao gồm các nhánh phát hành muộn hơn, chưa được xác lập và không nên tự suy ra là không bị ảnh hưởng.

Lỗi thuộc nhóm CWE-125 trong OpenEXRUtil, tại API SampleCountChannel::row(). API này được tài liệu hóa là truy cập hàng theo chỉ số 0-based, nhưng implementation lại tính địa chỉ từ _base, một con trỏ đã được điều chỉnh để hỗ trợ truy cập theo tọa độ pixel tuyệt đối. Khi dataWindow.min khác 0, hai mô hình tọa độ xung đột: at(dataWindow.min.x, dataWindow.min.y) vẫn trỏ đúng dữ liệu, còn row(0) có thể trỏ ra ngoài vùng cấp phát của _numSamples. Một tệp deep EXR do kẻ tấn công kiểm soát có thể cung cấp data window với gốc dọc âm lớn, khiến việc đọc sample count truy cập vùng heap ngoài giới hạn. Ảnh hưởng xảy ra khi ứng dụng mở tệp đó và sử dụng SampleCountChannel::row() để đọc sample counts. Bằng chứng hiện có xác nhận primitive là heap out-of-bounds read; chưa xác lập được khả năng ghi ngoài giới hạn hoặc thực thi mã từ riêng lỗi này.

Kẻ tấn công cần đưa một tệp deep EXR được tạo thủ công vào luồng xử lý của ứng dụng và khiến ứng dụng mở hoặc giải mã tệp đó. Theo các thuộc tính khai thác đã cung cấp, không cần xác thực hoặc quyền đặc biệt, nhưng vẫn cần user hoặc service tương tác với tệp. Việc khai thác có thể được thực hiện qua kênh mạng nếu ứng dụng nhận tệp từ xa, nhưng việc đọc lỗi chỉ xảy ra khi tệp được xử lý bởi code path bị ảnh hưởng. Advisory của nhà phát triển công bố các tệp PoC có thể tái hiện lỗi crash và một trường hợp đọc được dữ liệu heap lân cận trong bố cục heap được kiểm soát. Bằng chứng được cung cấp xác nhận public PoC, nhưng không xác lập việc khai thác trong thực tế, chiến dịch cụ thể hoặc nạn nhân cụ thể.

Tác động kỹ thuật trực tiếp là một heap out-of-bounds read khi code gọi truy cập sample counts thông qua SampleCountChannel::row(). Trường hợp đơn giản nhất là tiến trình giải mã bị crash, làm mất tính sẵn sàng của worker hoặc service. Với bố cục heap được kiểm soát, việc đọc có thể trả về các từ dữ liệu nằm cạnh buffer và tạo ra khả năng tiết lộ thông tin ở mức giới hạn. Lỗi không yêu cầu thay đổi phạm vi bảo mật của ứng dụng và bằng chứng hiện có không xác lập primitive ghi bộ nhớ hoặc thực thi mã. Một hệ thống chỉ bị exposure khi tệp deep EXR do kẻ tấn công kiểm soát đi tới code path bị ảnh hưởng.

• Một tệp EXR độc hại có thể làm crash worker hoặc service đang giải mã ảnh, gây gián đoạn các pipeline xử lý ảnh.
• Trong điều kiện heap phù hợp, dữ liệu nằm cạnh sample-count buffer có thể bị trả về cho code gọi và trở nên quan sát được, tạo nguy cơ lộ thông tin giới hạn trong tiến trình.
• Ảnh hưởng thực tế phụ thuộc vào việc tổ chức có nhận tệp EXR từ nguồn không tin cậy và có gọi code path SampleCountChannel::row() hay không.
• Bằng chứng của lỗi này không cho thấy khả năng sửa đổi dữ liệu hoặc một kịch bản breach cụ thể; tác động được xác nhận chủ yếu là mất tính sẵn sàng và khả năng tiết lộ dữ liệu heap.

1. Nâng cấp openexr lên bản sửa tương ứng với nhánh đang sử dụng: 3.2.11 cho nhánh 3.2, 3.3.13 cho nhánh 3.3 hoặc 3.4.14 cho nhánh 3.4.
2. Với các hệ thống đang chạy 2.x, 3.0.x hoặc 3.1.x, advisory xác nhận các nhánh này bị ảnh hưởng nhưng không nêu bản sửa cùng nhánh. Chuyển sang một bản phát hành đã được vendor xác nhận là đã sửa, sau khi kiểm thử tương thích.
3. Kiểm tra và triển khai lại toàn bộ ứng dụng, worker và công cụ có thể mang bản OpenEXRUtil riêng, không chỉ package hệ điều hành ở cấp máy chủ.
4. Nếu chưa thể nâng cấp ngay, ngăn các thành phần bị ảnh hưởng xử lý deep EXR không tin cậy hoặc cô lập bộ giải mã khỏi dữ liệu và quyền nhạy cảm. Đây là biện pháp giảm rủi ro tạm thời, không phải bản sửa đã được vendor xác nhận.

• Kiểm kê các ứng dụng, service và công cụ sử dụng OpenEXR hoặc OpenEXRUtil để mở deep EXR, bao gồm cả các bản thư viện được đóng gói cùng ứng dụng.
• Rà soát dependency và code usage để xác định nơi gọi SampleCountChannel::row() trên deep image, đặc biệt khi xử lý tệp có dataWindow không bắt đầu tại 0.
• Trong môi trường cô lập, kiểm thử đường dẫn mở tệp bằng PoC do advisory cung cấp; bật AddressSanitizer hoặc UndefinedBehaviorSanitizer để phát hiện read ngoài giới hạn.
• Rà soát crash telemetry và log của worker giải mã EXR để tìm SIGSEGV hoặc sanitizer report phát sinh trong quá trình đọc sample counts. Đây là dấu hiệu hỗ trợ điều tra, không phải IOC đặc hiệu và việc không có log không chứng minh hệ thống an toàn.
• Xác nhận trạng thái sau nâng cấp bằng inventory thực tế của từng binary hoặc package, thay vì chỉ kiểm tra version của build system.