Bug 1848518 (CVE-2020-12268)
Summary: | CVE-2020-12268 jbig2dec: heap-based buffer overflow in jbig2_image_compose in jbig2_image.c | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Dhananjay Arunesh <darunesh> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | unspecified | CC: | mjg, nforro, pzhukov |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2020-07-13 13:27:39 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1848520, 1848522, 1851055, 1851056, 1851057, 1851058 | ||
Bug Blocks: | 1848528 |
Description
Dhananjay Arunesh
2020-06-18 13:31:38 UTC
Created jbig2dec tracking bugs for this issue: Affects: fedora-all [bug 1848520] Created jbig2dec tracking bugs for this issue: Affects: epel-all [bug 1848522] Upstream fix: https://github.com/ArtifexSoftware/jbig2dec/commit/0726320a4b55078e9d8deb590e477d598b3da66e 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. 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. 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.) 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? 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 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 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 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 |