Bug 718918 – <media-libs/openjpeg-2.4.0: Multiple vulnerabilities (CVE-2019-12973, CVE-2020-{15389,27814,27841,27842,27843,27844,27845})

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description GLSAMaker/CVETool Bot 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 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 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 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 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 <[e-mail]>
AuthorDate: 2020-12-29 02:56:24 +0000
Commit:     Sam James <[e-mail]>
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 <[e-mail]>

 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 2021-01-06 03:09:52 UTC]

amd64 done

[Comment 6 Sam James 2021-01-06 06:34:21 UTC]

x86 done

[Comment 7 Sam James 2021-01-06 06:37:04 UTC]

arm done

[Comment 8 Sam James 2021-01-07 01:10:26 UTC]

arm64 done

[Comment 9 Sam James 2021-01-07 02:34:41 UTC]

ppc done

[Comment 10 Sam James 2021-01-07 10:42:10 UTC]

ppc64 done

[Comment 11 Sam James 2021-01-10 09:35:16 UTC]

sparc done

[Comment 12 Rolf Eike Beer 2021-01-17 12:33:45 UTC]

hppa stable

[Comment 13 Sam James 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 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 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 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 2021-02-11 08:14:23 UTC]

s390 done

all arches done

[Comment 19 Larry the Git Cow 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 <[e-mail]>
AuthorDate: 2021-02-11 08:15:38 +0000
Commit:     Sam James <[e-mail]>
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 <[e-mail]>

 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 2021-02-11 08:16:02 UTC]

All done! (Thanks slyfox for noticing the package list!)