Summary: | <media-libs/openjpeg-2.4.0: Multiple vulnerabilities (CVE-2019-12973, CVE-2020-{15389,27814,27841,27842,27843,27844,27845}) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | GLSAMaker/CVETool Bot <glsamaker> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ajak, graphics+disabled, maintainer-needed |
Priority: | Normal | Flags: | nattka:
sanity-check+
|
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=711260 https://bugs.gentoo.org/show_bug.cgi?id=756394 |
||
Whiteboard: | B2 [glsa+ cve] | ||
Package list: |
media-libs/openjpeg-2.4.0
|
Runtime testing required: | --- |
Bug Depends on: | |||
Bug Blocks: | 774015 |
Description
GLSAMaker/CVETool Bot
2020-04-22 17:31:35 UTC
CVE-2020-15389: "jp2/opj_decompress.c in OpenJPEG through 2.3.1 has a use-after-free that can be triggered if there is a mix of valid and invalid files in a directory operated on by the decompressor. Triggering a double-free may also be possible. This is related to calling opj_image_destroy twice." Upstream issue: https://github.com/uclouvain/openjpeg/issues/1261 Pull request: https://github.com/uclouvain/openjpeg/pull/1262 (In reply to GLSAMaker/CVETool Bot from comment #0) > CVE-2019-12973 (https://nvd.nist.gov/vuln/detail/CVE-2019-12973): > In OpenJPEG 2.3.1, there is excessive iteration in the opj_t1_encode_cblks > function of openjp2/t1.c. Remote attackers could leverage this > vulnerability > to cause a denial of service via a crafted bmp file. This issue is similar > to CVE-2018-6616. > > > Patches: > * > https://github.com/uclouvain/openjpeg/commit/ > 8ee335227bbcaf1614124046aa25e53d67b11ec3 > * https://github.com/uclouvain/openjpeg/pull/1185 > > Bug: https://github.com/uclouvain/openjpeg/issues/1222 This has been fixed since 2.3.1 (https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/openjpeg?id=1300f5f73c69b5d2e0352cdb0a5f8f5e169e0723, 11th April 2019). So we just need to do the 2020 use-after-free. (In reply to John Helmert III (ajak) from comment #1) > CVE-2020-15389: > > "jp2/opj_decompress.c in OpenJPEG through 2.3.1 has a use-after-free that > can be triggered if there is a mix of valid and invalid files in a directory > operated on by the decompressor. Triggering a double-free may also be > possible. This is related to calling opj_image_destroy twice." > > Upstream issue: https://github.com/uclouvain/openjpeg/issues/1261 > Pull request: https://github.com/uclouvain/openjpeg/pull/1262 2.4.0 is released and fixes this, along with numerous other security fixes (from the changelog): Heap-buffer-overflow in lib/openjp2/pi.c:312 #1302 Heap-buffer-overflow in lib/openjp2/t2.c:973 #1299 Heap-buffer-overflow in lib/openjp2/pi.c:623 #1293 Global-buffer-overflow in lib/openjp2/dwt.c:1980 #1286 Heap-buffer-overflow in lib/openjp2/tcd.c:2417 #1284 Heap use-after-free #1261 Memory leak when failing to allocate object... #1259 Memory leak of Tier 1 handle when OpenJPEG fails to set it as TLS... #1257 Another heap buffer overflow in libopenjp2 #1231 Heap buffer overflow in libopenjp2 #1228 Heap buffer overflow in opj_t1_clbl_decode_processor() triggered with Ghostscript #1158 opj_stream_get_number_byte_left: Assertion `p_stream->m_byte_offset >= 0' failed. #1151 out of bounds read #1068 Heap-buffer-overflow in lib/openjp2/mqc.c:499 #1283 The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=77e5ad18b2cc380826ad062461b08357633889a6 commit 77e5ad18b2cc380826ad062461b08357633889a6 Author: Sam James <sam@gentoo.org> AuthorDate: 2020-12-29 02:56:24 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-12-29 02:56:24 +0000 media-libs/openjpeg: security bump to 2.4.0 Bug: https://bugs.gentoo.org/675426 Bug: https://bugs.gentoo.org/718918 Closes: https://bugs.gentoo.org/715306 Closes: https://bugs.gentoo.org/715422 Closes: https://bugs.gentoo.org/715130 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Sam James <sam@gentoo.org> media-libs/openjpeg/Manifest | 2 + .../files/openjpeg-2.4.0-gnuinstalldirs.patch | 420 +++++++++++++++++++++ media-libs/openjpeg/openjpeg-2.4.0.ebuild | 139 +++++++ 3 files changed, 561 insertions(+) amd64 done x86 done arm done arm64 done ppc done ppc64 done sparc done hppa stable * CVE-2020-27814 Description: "A heap-buffer overflow was found in the way openjpeg2 handled certain PNG format files. An attacker could use this flaw to cause an application crash or in some cases execute arbitrary code with the permission of the user running such an application." https://github.com/uclouvain/openjpeg/issues/1283 This issue was resolved and addressed in GLSA 202101-29 at https://security.gentoo.org/glsa/202101-29 by GLSA coordinator Sam James (sam_c). Reopening for s390 then cleanup. Adding a note in case anyone else runs into this glsa-check error today, and searches for the latest media-libs/openjpeg bug to find this bug: # glsa-check -n -v -c -t affected Traceback (most recent call last): File "/usr/lib/python-exec/python3.7/glsa-check", line 139, in <module> if myglsa.isVulnerable(): File "/usr/lib/python3.7/site-packages/portage/glsa.py", line 650, in isVulnerable or (len(match(v, self.vardbapi)) > 0 \ File "/usr/lib/python3.7/site-packages/portage/glsa.py", line 296, in match return dbapi.match(atom) File "/usr/lib/python3.7/site-packages/portage/dbapi/vartree.py", line 567, in match origdep, mydb=self, use_cache=use_cache, settings=self.settings) File "/usr/lib/python3.7/site-packages/portage/dbapi/dep_expand.py", line 33, in dep_expand mydep = Atom(mydep, allow_repo=True) File "/usr/lib/python3.7/site-packages/portage/dep/__init__.py", line 1314, in __init__ raise InvalidAtom(self) portage.exception.InvalidAtom: <media-libs/openjpeg-*:1 There was a bad version specification in the first version of the GLSA for this issue. glsa-check will barf on it when parsing, whether you have media-libs/openjpeg installed or not. The fix has already been committed, but if you emerge --sync using snapshots (webrsync) you won't get it yet. Wait ~24 hours for a fixed snapshot to be available, or do a minimal fix by hand: # diff -u /usr/portage/metadata/glsa/glsa-202101-29.xml.orig /usr/portage/metadata/glsa/glsa-202101-29.xml --- /usr/portage/metadata/glsa/glsa-202101-29.xml.orig 2021-01-25 19:39:21.000000000 -0500 +++ /usr/portage/metadata/glsa/glsa-202101-29.xml 2021-01-26 12:41:20.700612431 -0500 @@ -15,7 +15,7 @@ <package name="media-libs/openjpeg" auto="yes" arch="*"> <unaffected range="ge" slot="2">2.4.0</unaffected> <vulnerable range="lt" slot="2">2.4.0</vulnerable> - <vulnerable range="lt" slot="1">*</vulnerable> + <vulnerable range="lt" slot="1">1.5.2-r1</vulnerable> </package> </affected> <background> # glsa-check -n -v -c -t affected This system is not affected by any of the listed GLSAs # (In reply to Hank Leininger from comment #16) > Adding a note in case anyone else runs into this glsa-check error today, and > searches for the latest media-libs/openjpeg bug to find this bug: > m: <media-libs/openjpeg-*:1 > > There was a bad version specification in the first version of the GLSA for > this issue. glsa-check will barf on it when parsing, whether you have > media-libs/openjpeg installed or not. The fix has already been committed, > but if you emerge --sync using snapshots (webrsync) you won't get it yet. > Wait ~24 hours for a fixed snapshot to be available, or do a minimal fix by > hand: > Yes, apologies for this -- it was fixed quite quickly but not fast enough to get into the snapshot. s390 done all arches done The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e31a773aa52771524f781a95e46c6c1904e6a08f commit e31a773aa52771524f781a95e46c6c1904e6a08f Author: Sam James <sam@gentoo.org> AuthorDate: 2021-02-11 08:15:38 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-02-11 08:15:38 +0000 media-libs/openjpeg: security cleanup Bug: https://bugs.gentoo.org/718918 Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Sam James <sam@gentoo.org> media-libs/openjpeg/Manifest | 2 - .../files/openjpeg-2.3.1-CVE-2020-6851.patch | 29 -- .../files/openjpeg-2.3.1-CVE-2020-8112.patch | 43 -- .../files/openjpeg-2.3.1-gnuinstalldirs.patch | 495 --------------------- .../files/openjpeg-2.3.1-libtiff-4.1-compat.patch | 210 --------- media-libs/openjpeg/openjpeg-2.3.1-r1.ebuild | 136 ------ 6 files changed, 915 deletions(-) All done! (Thanks slyfox for noticing the package list!) |