Out-of-bounds memory access due to malformed HDR image file #94572

New Issue

Albin Eldstål-Ahrens · 2022-01-02T11:56:32+01:00

2022-01-02 11:56:32 +01:00

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
An HDR image (loaded as a texture, for example) may specify a negative width or height, leading to invalid size and address calculations.

Cause
The parsing in imb_loadhdr declares int width and parses it from the input file using sscanf with the %d format at source/blender/imbuf/intern/radiance_hdr.c:252. There is no check for negative sizes such as -1.

Allocation of the ImBuf structure succeeds, since the internal MEM_callocN adds the size of a small structure before calling malloc(), thus ensuring that malloc is called with a reasonable (small) size parameter.

The end result is that a small pixel buffer is allocated, and ImBuf->x or ImBuf->y are negative.

Exact steps for others to reproduce the error
The following input file illustrates the problem.

oobw_rotate_54.hdr

#?RADIANCE

-Y 64 +X -1
0
666666666666666666666

The interesting fields are on the third line: "-Y" indicates that the image needs to be flipped. 64 is the height and -1 is the width.

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 oobw_rotate_54.hdr.

Impact
Depending on the input file and the flags parameter to imb_loadhdr, this can have one of several effects. The most severe is the potential for malicious code execution, as a consequence of out-of-bounds memory access.

Input file with "-Y" and a negative width
The call to IMB_flipy() at line 307 will lead to an out of bounds write.

Input file with "Y" and flag IB_rect used
The call to IMB_rect_from_float() at line 311 will lead to an out of bounds write.

Input file with "Y", negative width and flag IB_floatrect used
imb_loadhdr will fail to identify the fault and return an invalid ImBuf, which has a small pixel buffer allocated and negative dimensions. The potential impact of this ranges from a crash (out of bounds reads due to the small buffer) to potential code execution (out of bounds write on the small buffer).

Proposed mitigation
Check width and height right after parsing them with sscanf. There appears to be no reason to allow negative values.

**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** An HDR image (loaded as a texture, for example) may specify a negative width or height, leading to invalid size and address calculations. **Cause** The parsing in `imb_loadhdr` declares `int width` and parses it from the input file using `sscanf` with the `%d` format at source/blender/imbuf/intern/radiance_hdr.c:252. There is no check for negative sizes such as -1. Allocation of the ImBuf structure succeeds, since the internal `MEM_callocN` adds the size of a small structure before calling `malloc()`, thus ensuring that `malloc` is called with a reasonable (small) size parameter. The end result is that a small pixel buffer is allocated, and `ImBuf->x` or `ImBuf->y` are negative. **Exact steps for others to reproduce the error** The following input file illustrates the problem. [oobw_rotate_54.hdr](https://archive.blender.org/developer/F12785137/oobw_rotate_54.hdr) ``` #?RADIANCE -Y 64 +X -1 0 666666666666666666666 ``` The interesting fields are on the third line: "-Y" indicates that the image needs to be flipped. 64 is the height and -1 is the width. 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 `oobw_rotate_54.hdr`. **Impact** Depending on the input file and the `flags` parameter to `imb_loadhdr`, this can have one of several effects. The most severe is the potential for malicious code execution, as a consequence of out-of-bounds memory access. __Input file with "-Y" and a negative width__ The call to `IMB_flipy()` at line 307 will lead to an out of bounds write. __Input file with "Y" and flag `IB_rect` used__ The call to `IMB_rect_from_float()` at line 311 will lead to an out of bounds write. __Input file with "Y", negative width and flag `IB_floatrect` used__ `imb_loadhdr` will fail to identify the fault and return an invalid `ImBuf`, which has a small pixel buffer allocated and negative dimensions. The potential impact of this ranges from a crash (out of bounds reads due to the small buffer) to potential code execution (out of bounds write on the small buffer). **Proposed mitigation** Check `width` and `height` right after parsing them with `sscanf`. There appears to be no reason to allow negative values.

Albin Eldstål-Ahrens commented

2022-01-02 11:56:32 +01:00

Added subscriber: @eldstal

Jesse Yurkovich commented

2022-01-02 12:12:31 +01:00

Added subscriber: @deadpin

Jesse Yurkovich commented

2022-01-02 12:12:31 +01:00

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

Jesse Yurkovich commented

2022-01-02 12:12:31 +01:00

Confirmed, and it would be fixed with D11952. I'll push to get that committed sometime soon.

Confirmed, and it would be fixed with [D11952](https://archive.blender.org/developer/D11952). I'll push to get that committed sometime soon.

Albin Eldstål-Ahrens commented

2022-01-02 17:03:15 +01:00

Thanks for taking a look at this so quickly!

I can confirm that the patch in D11952 includes a fix for this issue.

Thanks for taking a look at this so quickly! I can confirm that the patch in [D11952](https://archive.blender.org/developer/D11952) includes a fix for this issue.

blender-admin commented

2022-01-12 05:48:32 +01:00

This issue was referenced by 1ee4e6bf31

This issue was referenced by 1ee4e6bf31ff32f87f9cd1eafa548d6811794380

blender-admin commented

2022-01-12 05:48:32 +01:00

This issue was referenced by 77616082f4

This issue was referenced by 77616082f44da5258faf9ec0d53618c721b88c62

Jesse Yurkovich commented

2022-01-12 05:59:26 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Jesse Yurkovich closed this issue