Skip to content

Security: sandflow/openexr-ht-private

Security

SECURITY.md

Security Policy

Reporting a Vulnerability

If you think you've found a potential vulnerability in OpenEXR, please report it by filing a GitHub security advisory. Alternatively, email [email protected] and provide your contact info for further private/secure discussion. If your email does not receive a prompt acknowledgement, your address may be blocked.

Our policy is to acknowledge the receipt of vulnerability reports within 48 hours. Our policy is to address critical security vulnerabilities rapidly and post patches within 14 days if possible.

Known Vulnerabilities

These vulnerabilities are present in the given versions:

See the release notes for more information.

Supported Versions

This gives guidance about which branches are supported with patches to security vulnerabilities.

Version / branch Supported
main ✅ 🚧 ALL fixes immediately, but this is a branch under development with a frequently unstable ABI and occasionally unstable API.
3.2.x ✅ All fixes that can be backported without breaking ABI compatibility.
3.1.x ⚠️ Only the most critical fixes, only if they can be easily backported.
3.0.x ⚠️ Only the most critical fixes, only if they can be easily backported.
2.5.x ⚠️ Only the most critical fixes, only if they can be easily backported.
<= 1.x ❌ No longer receiving patches of any kind.

Security Expectations

Software Features

  • The OpenEXR project implements the EXR image file format, used throughout the motion picture industry and beyond, on Linux, macOS, and Windows.

  • The project consists of a software run-time library, implemented in C/C++ and built via cmake, that reads and writes image data files. The project also distributes python wrappings for the C/C++ I/O API.

  • The library reads and writes binary image data and text-based metadata, treated as blind data, none of which is executable code.

  • Other than the website and online technical documentation, the project implements no web/online services or network communication protocols. The library never requests any security or authentication credentials or login information from users.

    The website implements no interactive features and requires no login credentials.

  • The library reads and writes only to file paths specificly requested via the C/C++ API. The runtime library uses no system configuration files or sidecar data files. Access to data files uses only standard file I/O system calls.

  • The library compresses/decompresses data via standard compression algorithms but uses no cryptographic or confidentiality protocols.

Software Dependencies

OpenEXR depends on Imath, a library of basic math operations also maintained and distributed by the OpenEXR project. Imath follows the same security conventions documented here for OpenEXR itself. The core Imath library has no external dependencies. The Imath python bindings depend on python and boost.

The only external library dependency of OpenEXR is libdeflate, which implements standard deflate/zlib/gzip compression and decompression.

The project uses Snyk to scan for dependency vulnerability.

Potential Vulnerabilities

Potential entry points are images being loaded using the library. Malformed images could caused issues such as heap buffer overflows, out-of-memory faults, or segmentation faults that could be exploitable as denial-of-service attacks.

Hardening

Testing

The OpenEXR project implements a comprehensive suite of validation tests, including fuzz testing to harden against malicious input data. Note that fuzz testing hardens only against small input data files and is not a comprehensive test against all potential input.

Note that the exrcheck utility is intended to be used by testers to demonstrate a particular proof-of-concept input file exposes a vulnerability, and it is very helpful to let us know if a vulnerability can be reproduced using that tool.

The project also uses the OSS Fuzz service for continuous fuzz testing.

Development Cycle and Distribution

OpenEXR is downloadable and buildable by C/C++ source via GitHub. Only members of the project's Technical Steering Committee, all veteran software engineers at major motion picture studios or vendors, have write permissions on the source code repository. All critical software changes are reviewed by multiple TSC members.

The library is distributed in binary form via many common package managers across all platforms.

There aren’t any published security advisories