Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NULL pointer dereference in stb_image.h #51

Closed
eldstal opened this issue Dec 14, 2021 · 9 comments · Fixed by #52
Closed

NULL pointer dereference in stb_image.h #51

eldstal opened this issue Dec 14, 2021 · 9 comments · Fixed by #52
Assignees

Comments

@eldstal
Copy link

eldstal commented Dec 14, 2021

This is a duplicate report of issue 160 in the original project. I'm not sure where best to report this, but it affects both projects.

Vulnerable versions

  • saitoha/libsixel at the latest (6a5be8b) commit
  • libsixel/libsixel at the latest (bc93c8c) commit

Steps to reproduce

img2sixel stbio_1561_poc.bin

Input file (a malformed PICT-format image) is attached

Cause

Segmentation fault in stbi__convert_format at stb_image.h:1561:

   switch (STBI__COMBO(img_n, req_comp)) {
     /* ... */
     STBI__CASE(4,3) { dest[0]=src[0],dest[1]=src[1],dest[2]=src[2]; } break;
     /* ... */
   }

The src pointer is NULL, as passed in from stbi__pic_load.

The source of the NULL pointer is the malloc at line 6120:

   result = (stbi_uc *) stbi__malloc_mad4(x, y, 4, 0);

whose output is never checked for NULL. The x and y dimensions (39168, 5888) are read
directly from the input file, and they pass the check in stbi__mad3sizes_valid which
only checks for integer overflow.

The total size of the allocated buffer is 39168 * 5888 * 4 and allocation fails.

Impact

Denial of service is the only obvious impact.

Mitigation

stb_image starting at version 2.27 (commit 50072f66589f52f51eb5b3f56b9272ea8ec1fdac) include a check for this condition. libsixel should be brought up-to-date with this version if possible.

If not, backport the check as well as similar error checks for other malloc calls.

@dankamongmen
Copy link
Collaborator

ugh, does libsixel have an undeclared vendored version of stb? ugh! thanks for the report, looking into it now for a possible quick fix.

@dankamongmen dankamongmen self-assigned this Dec 14, 2021
@dankamongmen
Copy link
Collaborator

yes, gross, why aren't we just using the system libstb-dev?

@dankamongmen
Copy link
Collaborator

Thanks a lot for the heads up, @eldstal . I've got a PR out which brings in 2.26, though I see from your original message that we actually need 2.27, so I'll get on that.

@eldstal
Copy link
Author

eldstal commented Dec 14, 2021

This must be the fastest turnaround I've ever seen on an issue. Good work, I hope you have time to eat and drink!

@dankamongmen dankamongmen reopened this Dec 14, 2021
@dankamongmen
Copy link
Collaborator

2.27 has been imported, fresh out of @nothing's tree. we ought unvendor this warty piece of shit, of course. god what a mistake it was to take over this library. hack on @eldstal !

@dankamongmen
Copy link
Collaborator

so this wasn't even supposed to be using STB, except for a bug where the compilie-time config wasn't being checked correctly. it now ought use libpng when present, and i'm thinking we ought yank out this vendored library.

@eli-schwartz
Copy link

yes, gross, why aren't we just using the system libstb-dev?

nothings/stb#359

Upstream is staunchly opposed to providing git tags, a build system, a binary library, a pkg-config file, or any combination of the above.

In the event you happen to be building for a Debian system, and nothing but a debian system, Debian provides a system package of libstb, with a number of "helpful" patches applied, such as 0001-Makefile-refactor.patch which "refactors" the Makefile by adding one in the first place.

(This Makefile then compiles and installs a Debian-specific libstb.so.0, stb.pc, etc.)

@dankamongmen
Copy link
Collaborator

good lord. i'd like to move ahead with #55, though at this point my hopes are really on dankamongmen/notcurses#2383.

@eldstal
Copy link
Author

eldstal commented Jan 25, 2022

This vulnerability has been assigned CVE-2021-45340. Thanks again for fixing it so quickly, best of luck with future development!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants