Out-of-bounds memory access in IMB_flipy() due to large image dimensions #94629

New Issue

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: Radeon RX 580 Series ATI Technologies Inc. 4.5.14761 Core Profile Context 21.10.3 30.0.13031.1001

Blender Version
Broken: version: 3.1.0 Alpha, branch: master, commit date: 2021-12-31 20:32, hash: 6844304dda
Broken: version: 2.93.8 Release Candidate, branch: master, commit date: 2021-12-15 14:37, hash: 59a48cc43d
Worked: -

Short description of error
A loaded (and valid) image (ImBuf*) can be crafted such that an out-of-bounds read or write occurs when the image is flipped vertically. In at least one IMB loader, flipping is performed on image load and without further user input.

Cause
IMB_flipy() in source/blender/imbuf/intern/rotate.c is missing a bounds check after lines 48 and 71. As a result, a in ImBuf with large dimensions can cause bottomf to wrap around and point to an address before topf.

By tuning the dimensions of the image carefully, an attacker can choose exactly where bottomf points, and have data written there from the input image.

Notes
While the provided example is an HDR image, this issue is independent of the HDR parsing code and thus also of the fix in D11952.

Exact steps for others to reproduce the error
The following input file (an HDR image) illustrates the problem. Call imb_loadhdr() with flags=IB_rectfloat on it to trigger a crash in IMB_flipy().

segv_rotate_78.hdr

#?RADIANCE

-Y 96
-Y 9630838

To see the crash in the latest alpha build of Blender, follow these steps:

Start with the default new project
Open the material panel.
Set the material "base color" of the default cube to "Image texture"
Load the texture file segv_rotate_78.hdr.

Impact
An attacker-controlled out-of-bounds write can realistically be used to obtain code execution in the blender process. For example, a return address on the stack or a function pointer in a known location in memory can be overwritten.

Proposed mitigation
Fail if bottomf <= topf, in both codepaths. I'm not able to provide a trivial patch for this, since IMB_flipy() has not been designed with a failure mechanism. Someone better acquainted with the various users of flipy needs to weigh in on a proper fix.

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: Radeon RX 580 Series ATI Technologies Inc. 4.5.14761 Core Profile Context 21.10.3 30.0.13031.1001 **Blender Version** Broken: version: 3.1.0 Alpha, branch: master, commit date: 2021-12-31 20:32, hash: `6844304dda` Broken: version: 2.93.8 Release Candidate, branch: master, commit date: 2021-12-15 14:37, hash: `59a48cc43d` Worked: - **Short description of error** A loaded (and valid) image (`ImBuf*`) can be crafted such that an out-of-bounds read or write occurs when the image is flipped vertically. In at least one IMB loader, flipping is performed on image load and without further user input. **Cause** `IMB_flipy()` in `source/blender/imbuf/intern/rotate.c` is missing a bounds check after lines 48 and 71. As a result, a in ImBuf with large dimensions can cause `bottomf` to wrap around and point to an address before `topf`. By tuning the dimensions of the image carefully, an attacker can choose exactly where `bottomf` points, and have data written there from the input image. **Notes** While the provided example is an HDR image, this issue is independent of the HDR parsing code and thus also of the fix in [D11952](https://archive.blender.org/developer/D11952). **Exact steps for others to reproduce the error** The following input file (an HDR image) illustrates the problem. Call `imb_loadhdr()` with `flags=IB_rectfloat` on it to trigger a crash in `IMB_flipy()`. [segv_rotate_78.hdr](https://archive.blender.org/developer/F12788416/segv_rotate_78.hdr) ``` #?RADIANCE -Y 96 -Y 9630838 ``` To see the crash in the latest alpha build of Blender, follow these steps: 1. Start with the default new project 2. Open the material panel. 3. Set the material "base color" of the default cube to "Image texture" 4. Load the texture file `segv_rotate_78.hdr`. **Impact** An attacker-controlled out-of-bounds write can realistically be used to obtain code execution in the blender process. For example, a return address on the stack or a function pointer in a known location in memory can be overwritten. **Proposed mitigation** Fail if `bottomf <= topf`, in both codepaths. I'm not able to provide a trivial patch for this, since `IMB_flipy()` has not been designed with a failure mechanism. Someone better acquainted with the various users of `flipy` needs to weigh in on a proper fix.

Added subscriber: @eldstal

Changed status from 'Needs Triage' to: 'Confirmed'

The proposed fix is useful, but insufficient.

A large enough ibuf->x can also cause the size to overflow before the call to MEM_mallocN() for the linef buffer. The buffer ends up with an allocation of the wrong size, leading to a different out-of-bounds access in the loop that follows.

The proposed fix is useful, but insufficient. A large enough `ibuf->x` can also cause the size to overflow before the call to `MEM_mallocN()` for the `linef` buffer. The buffer ends up with an allocation of the wrong size, leading to a different out-of-bounds access in the loop that follows.

In addition, some dimensions such as x=844193 and y=6364 are such that bottomf wraps around and then passes topf, resulting in bottomf > topf which may look safe. During the loop, however, bottomf will eventually be decremented to fall below topf and once again trigger the fault.

In addition, some dimensions such as `x=844193` and `y=6364` are such that `bottomf` wraps around and then passes `topf`, resulting in `bottomf > topf` which may look safe. During the loop, however, `bottomf` will eventually be decremented to fall below `topf` and once again trigger the fault.

This issue was referenced by 63fdcbb588

This issue was referenced by 63fdcbb5889e31b5f07d8d5c8e923cc57900fe1b

This issue was referenced by e07f16776b

This issue was referenced by e07f16776bca5e9494e6b143170f31d5eeb160ce

This issue was referenced by 82858ca3f4

This issue was referenced by 82858ca3f4e6dc6f840af9306c350900abd491fc

Changed status from 'Confirmed' to: 'Resolved'

This vulnerability has been assigned CVE-2022-0545 by the Red Hat CNA.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Out-of-bounds memory access in IMB_flipy() due to large image dimensions #94629