Bug 2015229 (CVE-2021-28021) - CVE-2021-28021 stb: buffer overflow in stbi__extend_receive() in stb_image.h via a crafted JPEG file
Summary: CVE-2021-28021 stb: buffer overflow in stbi__extend_receive() in stb_image.h ...
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2021-28021
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 2015716 2015231 2015232
Blocks: 2015230
TreeView+ depends on / blocked
 
Reported: 2021-10-18 17:14 UTC by Guilherme de Almeida Suckevicz
Modified: 2021-11-03 01:11 UTC (History)
4 users (show)

Fixed In Version: stb_image 2.27@86b7570cfba845e8209c6aec2d15e487bb1d8bb4
Doc Type: If docs needed, set a value
Doc Text:
An out-of-bounds read flaw was found in stb. This flaw allows an attacker who can submit a specially crafted file to an application using stb's JPEG decoder to cause a denial of service or information disclosure, depending on how the application uses the vulnerable stb functionality. The highest threat from this vulnerability is to confidentiality and system availability.
Clone Of:
Environment:
Last Closed: 2021-11-02 23:39:32 UTC


Attachments (Terms of Use)

Description Guilherme de Almeida Suckevicz 2021-10-18 17:14:20 UTC
Buffer overflow vulnerability in function stbi__extend_receive in stb_image.h in stb 2.26 via a crafted JPEG file.

Reference:
https://github.com/nothings/stb/issues/1108

Comment 1 Guilherme de Almeida Suckevicz 2021-10-18 17:15:54 UTC
Created stb tracking bugs for this issue:

Affects: epel-all [bug 2015232]
Affects: fedora-all [bug 2015231]

Comment 2 Ben Beasley 2021-10-18 18:44:06 UTC
I am the maintainer of the “stb” package in Fedora and in EPEL.

The separate stb package in Fedora (and EPEL8 and EPEL7) is only a couple of months old, and the oldest packaged stb_image version was 2.27. Nevertheless, the initial packaged version was affected by this CVE, as explained in the following paragraph.

The CVE text claims the latest affected version is 2.26, but this is not quite right. The upstream fix in https://github.com/nothings/stb/commit/5ba0baaa269b3fd681828e0e3b3ac0f1472eaf40 came after the bump to stb_image 2.27 in https://github.com/nothings/stb/commit/3a7dcdd2696ed7b85f892f951b0801e382b81778—so even though the “stb” package has never contained stb_image 2.26 or earlier, the initial package *was* affected by the CVE, and the current version *is not* affected, even though both provide stb_image 2.27. Is that confusing enough?

The following are the Bodhi updates (each already in stable) in which the CVE was corrected.

F36: https://bodhi.fedoraproject.org/updates/FEDORA-2021-35ace22099
F35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f049bf1e9a
F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-91a1112a15
F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7251e0ffa8
EPEL8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a3ef29c6c4
EPEL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-def1471d2b

Accordingly, there is no need for a further update to the stb package in response to this issue.

Since stb_image is a header-only library, fully eradicating vulnerable code associated with the “stb” package would require rebuilding any package that depends on “stb_image-devel” and/or “stb_image-static”.

Furthermore, since stb libraries are designed for bundling, it is likely that vulnerable versions do remain bundled with other packages in the distribution—either properly marked with “Provides: bundled(stb_image) = […]”, or, quite commonly, undetected. Wherever possible, I suggest migrating any such packages to use the unbundled stb_image-devel/stb_image-static provided here. I’m happy to assist with any such efforts upon request.

Please let me know if there is anything I can do.

Comment 5 Todd Cullum 2021-10-19 22:56:14 UTC
Flaw summary:

In stb_image.h, a crafted JPEG file could cause stbi__jpeg_huff_decode() to return values out-of-range which were then passed as the 'n' argument into stbi__extend_receive(). The max 'n' value that stbi_extend_receive() is designed to handle is <= 15, and values outside of this range can trigger an out-of-bounds read in global memory.

Comment 6 Todd Cullum 2021-10-19 23:03:52 UTC
In reply to comment #2:
> The CVE text claims the latest affected version is 2.26, but this is not
> quite right. The upstream fix in
> https://github.com/nothings/stb/commit/
> 5ba0baaa269b3fd681828e0e3b3ac0f1472eaf40 came after the bump to stb_image
> 2.27 in
> https://github.com/nothings/stb/commit/
> 3a7dcdd2696ed7b85f892f951b0801e382b81778—so even though the “stb” package
> has never contained stb_image 2.26 or earlier, the initial package *was*
> affected by the CVE, and the current version *is not* affected, even though
> both provide stb_image 2.27. Is that confusing enough?

> Please let me know if there is anything I can do.
Hi,

So in essence, you're saying that version 2.27 is both affected and unaffected because the patch was applied but not during a version bump (in fact, after one)? So it would be misleading to state that the "fixed version" is 2.27 because there are 2.27s floating around out there that are also vulnerable? Is this a fair statement?

Comment 7 Ben Beasley 2021-10-19 23:09:10 UTC
> So in essence, you're saying that version 2.27 is both affected and unaffected because the patch was applied but not during a version bump (in fact, after one)? So it would be misleading to state that the "fixed version" is 2.27 because there are 2.27s floating around out there that are also vulnerable? Is this a fair statement?

Yes, exactly.

Comment 8 Todd Cullum 2021-10-19 23:14:37 UTC
In reply to comment #7:
> > So in essence, you're saying that version 2.27 is both affected and unaffected because the patch was applied but not during a version bump (in fact, after one)? So it would be misleading to state that the "fixed version" is 2.27 because there are 2.27s floating around out there that are also vulnerable? Is this a fair statement?
> 
> Yes, exactly.

Oh lovely, thanks for the heads up...

Comment 9 Ben Beasley 2021-10-22 17:01:05 UTC
As a heads-up, see also the similar flaw https://nvd.nist.gov/vuln/detail/CVE-2021-42716, which affects stb_image 2.27. It was reported 2021-07-14 and assiged a CVE yesterday (2021-10-21). No official fix is yet available.

Comment 10 Ben Beasley 2021-10-22 17:27:51 UTC
Aaaaaand also https://nvd.nist.gov/vuln/detail/CVE-2021-42715.

It turns out there is a PR open to fix both CVE-2021-42715 and CVE-2021-42716. I just applied that PR as a downstream patch in Rawhide and will be rolling out updates for stable Fedora and EPEL releases.

All of that has, strictly speaking, nothing to do with *this* issue and CVE.

Comment 11 Owen Taylor 2021-10-28 16:33:43 UTC
To clarify the status for cogl and clutter.

The cogl library contains an old version of stb_image.c, however this is only compiled in when cogl in when gdk-pixbuf support is disabled. cogl as shipped in  RHEL and Fedora uses gdk-pixbuf, so is not affected by this vulnerability.  This also applies to the bundled copy of cogl inside clutter in RHEL 6 and very old versions of Fedora.

Comment 12 Fedora Update System 2021-10-31 01:08:28 UTC
FEDORA-2021-001f25d986 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 13 Fedora Update System 2021-11-02 01:11:01 UTC
FEDORA-2021-8ea648186c has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 14 Fedora Update System 2021-11-03 01:11:14 UTC
FEDORA-2021-16d848834d has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.