Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 718918 (CVE-2019-12973, CVE-2020-15389, CVE-2020-27814, CVE-2020-27841, CVE-2020-27842, CVE-2020-27843, CVE-2020-27844, CVE-2020-27845) - <media-libs/openjpeg-2.4.0: Multiple vulnerabilities (CVE-2019-12973, CVE-2020-{15389,27814,27841,27842,27843,27844,27845})
Summary: <media-libs/openjpeg-2.4.0: Multiple vulnerabilities (CVE-2019-12973, CVE-202...
Status: RESOLVED FIXED
Alias: CVE-2019-12973, CVE-2020-15389, CVE-2020-27814, CVE-2020-27841, CVE-2020-27842, CVE-2020-27843, CVE-2020-27844, CVE-2020-27845
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B2 [glsa+ cve]
Keywords:
Depends on:
Blocks: CVE-2021-21159, CVE-2021-21160, CVE-2021-21161, CVE-2021-21162, CVE-2021-21163, CVE-2021-21165, CVE-2021-21166, CVE-2021-21167, CVE-2021-21168, CVE-2021-21169, CVE-2021-21170, CVE-2021-21171, CVE-2021-21172, CVE-2021-21173, CVE-2021-21174, CVE-2021-21175, CVE-2021-21176, CVE-2021-21177, CVE-2021-21178, CVE-2021-21179, CVE-2021-21180, CVE-2021-21181, CVE-2021-21182, CVE-2021-21183, CVE-2021-21184, CVE-2021-21185, CVE-2021-21186, CVE-2021-21187, CVE-2021-21188, CVE-2021-21189, CVE-2021-21190
  Show dependency tree
 
Reported: 2020-04-22 17:31 UTC by GLSAMaker/CVETool Bot
Modified: 2021-03-02 21:27 UTC (History)
3 users (show)

See Also:
Package list:
media-libs/openjpeg-2.4.0
Runtime testing required: ---
nattka: sanity-check+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description GLSAMaker/CVETool Bot gentoo-dev 2020-04-22 17:31:35 UTC
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
Comment 1 John Helmert III archtester Gentoo Infrastructure gentoo-dev Security 2020-06-29 22:40:50 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
Comment 2 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-08-30 03:47:18 UTC
(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.
Comment 3 John Helmert III archtester Gentoo Infrastructure gentoo-dev Security 2020-12-29 02:04:06 UTC
(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
Comment 4 Larry the Git Cow gentoo-dev 2020-12-29 02:59:28 UTC
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(+)
Comment 5 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-01-06 03:09:52 UTC
amd64 done
Comment 6 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-01-06 06:34:21 UTC
x86 done
Comment 7 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-01-06 06:37:04 UTC
arm done
Comment 8 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-01-07 01:10:26 UTC
arm64 done
Comment 9 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-01-07 02:34:41 UTC
ppc done
Comment 10 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-01-07 10:42:10 UTC
ppc64 done
Comment 11 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-01-10 09:35:16 UTC
sparc done
Comment 12 Rolf Eike Beer archtester 2021-01-17 12:33:45 UTC
hppa stable
Comment 13 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-01-25 20:13:09 UTC
* 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
Comment 14 GLSAMaker/CVETool Bot gentoo-dev 2021-01-26 00:23:09 UTC
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).
Comment 15 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-01-26 00:58:32 UTC
Reopening for s390 then cleanup.
Comment 16 Hank Leininger 2021-01-26 17:45:45 UTC
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
#
Comment 17 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-01-26 17:47:02 UTC
(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.
Comment 18 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-02-11 08:14:23 UTC
s390 done

all arches done
Comment 19 Larry the Git Cow gentoo-dev 2021-02-11 08:15:44 UTC
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(-)
Comment 20 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-02-11 08:16:02 UTC
All done! (Thanks slyfox for noticing the package list!)