Описание
OpenEXR has buffer overflow in PyOpenEXR_old's channels() and channel()
Summary
A memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects.
Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit).
This bug was found with ZeroPath.
Details
Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit), around here.
-
In
channel():-
Width and height are derived from the header dataWindow using
int. -
typeSizeis asize_t. The buffer size is computed astypeSize * width * heightwith no bounds checks. -
The result is passed to
PyString_FromStringAndSize(NULL, size)which maps toPyBytes_FromStringAndSize. That function expectsPy_ssize_t. If the product overflows or exceedsPY_SSIZE_T_MAX, allocation fails or the value wraps. -
The return value is not checked. The code immediately calls
PyString_AsString(r)and proceeds to build aFrameBufferand callsreadPixels(miny, maxy). -
On 64 bit:
PyBytes_FromStringAndSizereturns NULL, the wrapper dereferences NULL and crashes.
On 32 bit: the multiplication can wrap to a small positive size, producing a too-small allocation, after whichreadPixelswritestypeSize * widthbytes per scanline forheightlines into that buffer, causing a heap overflow.
-
-
In
channels()the same pattern appears for each requested channel. It also ignores per-channel subsampling when computing the allocation and when inserting theSliceit hardcodesxSampling=1, ySampling=1. If a file actually has subsampled channels this makes the stride and allocation inconsistent, which can also lead to over or under writes.
PoC
Impact
Typical memory stuff.
Пакеты
OpenEXR
>= 3.2.0, < 3.2.5
3.2.5
OpenEXR
>= 3.3.0, < 3.3.6
3.3.6
OpenEXR
>= 3.4.0, < 3.4.3
3.4.3
Связанные уязвимости
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.
OpenEXR provides the specification and reference implementation of the ...