Bug 1848518 (CVE-2020-12268) - CVE-2020-12268 jbig2dec: heap-based buffer overflow in jbig2_image_compose in jbig2_image.c
Summary: CVE-2020-12268 jbig2dec: heap-based buffer overflow in jbig2_image_compose in...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2020-12268
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1848520 1848522 1851055 1851056 1851057 1851058
Blocks: 1848528
TreeView+ depends on / blocked
 
Reported: 2020-06-18 13:31 UTC by Dhananjay Arunesh
Modified: 2020-07-21 14:33 UTC (History)
3 users (show)

Fixed In Version: jbig2dec 0.18
Doc Type: If docs needed, set a value
Doc Text:
An integer overflow was found in jbig2dec, which causes an out-of-bounds read/write in the jbig2_image_compose function. This flaw could potentially result in the execution of code on the system. Applications that use jbig2dec with untrusted input may be vulnerable to this flaw. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
Clone Of:
Environment:
Last Closed: 2020-07-13 13:27:39 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:2897 0 None None None 2020-07-13 11:09:41 UTC
Red Hat Product Errata RHSA-2020:2971 0 None None None 2020-07-16 08:40:52 UTC
Red Hat Product Errata RHSA-2020:3043 0 None None None 2020-07-21 14:33:26 UTC

Description Dhananjay Arunesh 2020-06-18 13:31:38 UTC
A vulnerability was found in jbig2_image_compose in jbig2_image.c in Artifex jbig2dec before 0.18 has a heap-based buffer overflow.

References:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20332
https://github.com/ArtifexSoftware/jbig2dec/commit/0726320a4b55078e9d8deb590e477d598b3da66e
https://github.com/ArtifexSoftware/jbig2dec/compare/0.17...0.18

Comment 1 Dhananjay Arunesh 2020-06-18 13:33:28 UTC
Created jbig2dec tracking bugs for this issue:

Affects: fedora-all [bug 1848520]

Comment 2 Dhananjay Arunesh 2020-06-18 13:34:00 UTC
Created jbig2dec tracking bugs for this issue:

Affects: epel-all [bug 1848522]

Comment 5 Riccardo Schirone 2020-06-25 13:58:18 UTC
Due to an integer overflow during a multiplication used in jbig2_image_compose(), it is possible to cause an out-of-bound read/write in the jbig2dec library, which could potentially result in the execution of code on the system. Applications that use jbig2dec with untrusted input may be vulnerable to this flaw.

Comment 6 Riccardo Schirone 2020-06-25 13:59:57 UTC
Red Hat Enterprise Linux 8 just ships jbig2dec-libs, so no custom application can be built against this library, however there are existing packages that use jbig2dec-libs, such as libgs, which in turn is used by ghostscript, graphviz, gimp and others.

Comment 8 Michael J Gruber 2020-06-25 14:14:49 UTC
I'm sorry I can't make much sense out of these bug reports against old versions.

As far as I can see, everything is (well: all those reported bugs are) fixed in current releases and there is no jbig2dec in epel8.
I have no control over jbig2dec-libs in epel8, and in fact that held up getting jbig2dec into epel8.

epel7 is based on an ancient Fedora. The RHEL/EPEL criteria keep me from updating any epel package to current versions. This basically contradicts having *any* artifex software in EPEL: it is notoriously buggy, there are no maintenance (bugfix) branches, and parts like jbig2dec have no abi stability whatsover, which practically requires packagers to update to *the* current release, hopefully coordinating with other packagers if they don't have their dependencies explicit enough. This does not scale and is too complicated for me poor little fedora maintainer.

In short:
- As much of artifex's stuff should be in the hands of very few developpers.
- EPEL requirements do not match my time constraints.

Feel free to take any EPEL branches that are currently assigned to me. (We used to be able to simply give them away, nowadays it's tickets, I guess.)

Comment 9 Riccardo Schirone 2020-07-02 06:47:21 UTC
In reply to comment #8:
> I'm sorry I can't make much sense out of these bug reports against old
> versions.
> 
> As far as I can see, everything is (well: all those reported bugs are) fixed
> in current releases and there is no jbig2dec in epel8.
> I have no control over jbig2dec-libs in epel8, and in fact that held up
> getting jbig2dec into epel8.

Those bugs are not only for Fedora 32 or EPEL 8, but for all supported Fedora/EPEL. So, for example, Fedora 31, which is still supported, ships jbig2dec-0.16, which is potentially vulnerable to this flaw. As part of our process, we notify maintainers in community projects about the (possible) issue, but then it is up to you to choose what to do.

> epel7 is based on an ancient Fedora. The RHEL/EPEL criteria keep me from
> updating any epel package to current versions. This basically contradicts
> having *any* artifex software in EPEL: it is notoriously buggy, there are no
> maintenance (bugfix) branches, and parts like jbig2dec have no abi stability
> whatsover, which practically requires packagers to update to *the* current
> release, hopefully coordinating with other packagers if they don't have
> their dependencies explicit enough. This does not scale and is too
> complicated for me poor little fedora maintainer.
> 
> In short:
> - As much of artifex's stuff should be in the hands of very few developpers.
> - EPEL requirements do not match my time constraints.

As said, we notify maintainers about the possible security issues, then it is up to you if, when and how to address them. Some will backport the fixes, others will update to current release, some may be able to fix it only on latest version of the project (e.g. Fedora 32) and not on all of them. Of course we can't know how each component works upstream, whether it is easy or not for you to backport the patch or fix it somehow.

> Feel free to take any EPEL branches that are currently assigned to me. (We
> used to be able to simply give them away, nowadays it's tickets, I guess.)

What does this mean exactly?

Comment 10 errata-xmlrpc 2020-07-13 11:09:39 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2020:2897 https://access.redhat.com/errata/RHSA-2020:2897

Comment 11 Product Security DevOps Team 2020-07-13 13:27:39 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2020-12268

Comment 12 errata-xmlrpc 2020-07-16 08:40:49 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.1 Extended Update Support

Via RHSA-2020:2971 https://access.redhat.com/errata/RHSA-2020:2971

Comment 13 errata-xmlrpc 2020-07-21 14:33:23 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.0 Update Services for SAP Solutions

Via RHSA-2020:3043 https://access.redhat.com/errata/RHSA-2020:3043


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