Bug 19497 - openjpeg new security issue CVE-2016-7445
Summary: openjpeg new security issue CVE-2016-7445
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/702317/
Whiteboard: has_procedure MGA5-32-OK MGA5-64-OK a...
Keywords: validated_update
Depends on:
Reported: 2016-09-30 21:57 CEST by David Walser
Modified: 2016-10-23 10:50 CEST (History)
6 users (show)

See Also:
Source RPM: openjpeg-1.5.2-5.mga5.src.rpm
Status comment:


Description David Walser 2016-09-30 21:57:41 CEST
openSUSE has issued an advisory today (September 30):

This CVE was originally issued for openjpeg2 (for code that was only there) but there must have been some variant of the issue present in some older code in openjpeg.

Patched packages uploaded for Mageia 5 and Cauldron.

The openjpeg2 package will be addressed in Bug 17536.


Updated openjpeg packages fix security vulnerability:

The openjpeg library was vulnerable to a crash when converting images due to a
NULL pointer dereference in read_pnm_header() (CVE-2016-7445).


Updated packages in core/updates_testing:

from openjpeg-1.5.2-5.1.mga5.src.rpm
Comment 1 Len Lawrence 2016-09-30 23:52:16 CEST
Testing on x86_64 real hardware.

Downloaded the PoC image from http://seclists.org/oss-sec/2016/q3/546.
Not obvious how to test the file although there is a specimen ASAN dump in one of the reference files which demonstrates a failure when the convert.c function is called.

$ opj_compress -i openjpeg-nullptr-github-issue-842.ppm -o test.jp2
pnmtoimage:Failed to open poc.ppm for reading!
Unable to load pnm file

Updated the openjpeg packages.
Note that openjpeg2 and its libraries had already been updated.
$ opj_compress -i openjpeg-nullptr-github-issue-842.ppm -o poc.jp2
Segmentation fault

This probably shows that the code now handles PNM formats.
This is what strace shows:
open("openjpeg-nullptr-github-issue-842.ppm", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=114464, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9a94118000
read(3, "P6\n# OpenJPEG-2.0.0\212256 149\n255\n"..., 4096) = 4096
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV +++

This looks OK to me.  It should be independent of the openjpeg2 bug?  WDYT David?

CC: (none) => tarazed25

Comment 2 David Walser 2016-09-30 23:58:36 CEST
It is independent of the openjpeg2 bug.  It looks like ASAN isn't needed here since it actually segfaults.  It looks like your test is reasonable.  I wouldn't expect openjpeg to be able to handle jp2 as an output format, but the segfault is in reading the input PoC file, so perhaps it doesn't matter.  As long as it doesn't segfault after the update, should be OK.
Comment 3 Len Lawrence 2016-10-01 00:50:05 CEST
This is where I am confused.  The segfault occurred after the update; before that it simply failed to handle PNM.  openjpeg2 is updated (I think, local build) and that is called here by opj_compress.  It looks like the successful open is in the openjpeg code then read is called from somewhere and segfaults after reading the header.  So you reckon the fault is supposed to be handled more politely?  In that case the update does not look OK.
Comment 4 David Walser 2016-10-01 00:52:33 CEST
Oh I see, opj_compress is from openjpeg2 so wouldn't be a valid test here for openjpeg.  You would need a tool from openjpeg to test reading the PNM file.
Comment 5 Len Lawrence 2016-10-01 09:27:42 CEST
That is what I figured initially but could not find an openjpeg tool.  Had better do some more research.  Thanks.
Comment 6 Len Lawrence 2016-10-01 10:02:04 CEST
Installed lib64openjpeg-devel which supplies j2k_dump and j2k_to_image.
Comment 7 Len Lawrence 2016-10-01 10:52:59 CEST
Moved to another machine, renamed the PoC file and tried:
$ image_to_j2k -i poc.ppm -o poc.jp2
which failed with the "Unable to load pnm file" message.
No segfault.
Updated the openjpeg packages from Updates Testing and obtained a stack trace which ends with:
open("poc.ppm", O_RDONLY)               = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=114464, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5cb125e000
read(3, "P6\n# OpenJPEG-2.0.0\212256 149\n255\n"..., 4096) = 4096
close(3)                                = 0
munmap(0x7f5cb125e000, 4096)            = 0
write(2, "Unable to load pnm file\n", 24Unable to load pnm file
) = 24
exit_group(1)                           = ?
+++ exited with 1 +++

Again, no segfault, which seems inconclusive wrt this bug.
Comment 8 Len Lawrence 2016-10-01 21:40:52 CEST
Tried yet another machine and verified that the strace output is virtually identical when running the PoC file through image_to_j2k.
Comment 9 Len Lawrence 2016-10-01 21:41:41 CEST
Sorry, meant to add "both before and after the updates".
Nicolas Lécureuil 2016-10-09 11:18:28 CEST

CC: (none) => mageia
Whiteboard: (none) => has_procedure

Comment 10 Nicolas Lécureuil 2016-10-09 11:26:43 CEST
no egfault here, before and after the new package, only the "Unable to load pnm file" error.
Comment 11 William Kenney 2016-10-12 19:21:03 CEST
In VirtualBox, M5, KDE, 32-bit

[root@localhost wilcal]# urpmi openjpeg
Package openjpeg-1.5.2-5.mga5.i586 is already installed

I've tinkered with this thing and can't find any logical,
simple, easy to understand way to test it.

CC: (none) => wilcal.int

Comment 12 David Walser 2016-10-12 20:12:21 CEST
The PoC was written for openjpeg2, so we may not have a PoC for openjpeg.  For general testing, it's a library (libopenjpeg5) used by several applications.
Comment 13 William Kenney 2016-10-12 20:58:01 CEST
(In reply to David Walser from comment #12)

> The PoC was written for openjpeg2, so we may not have a PoC for openjpeg. 
> For general testing, it's a library (libopenjpeg5) used by several
> applications.

Do you have any idea on which application(s) use it?
Comment 14 David Walser 2016-10-12 21:17:42 CEST
As usual, urpmq is your friend.

urpmq --whatrequires libopenjpeg5, shows darktable, krita, and mtpaint, as well as a few other libraries.
Comment 15 Len Lawrence 2016-10-12 22:57:40 CEST
urpmq -i krita returns:
Krita is a KDE program for sketching and painting, offering an endâtoâend
solution for creating digital painting files from scratch by masters.

Worth a try.
Comment 16 Herman Viaene 2016-10-15 12:01:38 CEST
MGA5-32 on Acer D620 Xfce
No installation issues
Used "strace -o Documenten/mtpaint.txt mtpaint" , opened and saved a jpeg file in mtpaint, and found in mtpaint.txt a call to /lib/libopenjpeg.so.5 on opening the file.

CC: (none) => herman.viaene
Whiteboard: has_procedure => has_procedure MGA5-32-OK

Comment 17 Lewis Smith 2016-10-19 21:19:56 CEST
Prior to testing M5-64
openjpeg provides the following commands:
Main applications using lib64openjpeg5 (copy of Comment 14): darktable, krita, mtpaint - and not to overlook openjpeg itself!

CC: (none) => lewyssmith

Comment 18 Lewis Smith 2016-10-20 00:57:02 CEST
Testing Mageia 5 x64 real hardware

BEFORE update:
 libopenjpeg5-1.5.2-5.mga5   [Do not know why this is here]

 $ image_to_j2k -i tuesday-w2.bmp -o ~/tmp/images/tuesday-w2.j2k
 Error, unknown BMP header size 124
 Unable to load bmp file
but the source BMP file is viewable. So this conversion failed.

 $ image_to_j2k -i blackbuck.png -o ~/tmp/images/blackbuck.j2k
 Generated outfile /home/lewis/tmp/images/blackbuck.j2k

 $ image_to_j2k -i bell_206.ppm -o ~/tmp/images/bell_206.ppm.j2k
 $ image_to_j2k -i ElderChmpgn.tiff -o ~/tmp/images/ElderChmpgn.j2k
Both 'successful' as per the previous example.
BUT *nothing* I have could open the j2k images thus produced *except* Darktable.

However, itself was happy with what it had produced:
 $ j2k_dump -i /home/lewis/tmp/images/bell_206.j2k
 $ j2k_dump -i /home/lewis/tmp/images/blackbuck.j2k
 $ j2k_dump -i /home/lewis/tmp/images/ElderChmpgn.j2k
all yielded a lot of neat formatted output without errors.
 $ j2k_to_image -i /home/lewis/tmp/images/blackbuck.j2k -o /home/lewis/tmp/images/blackbuck.bmp
 Generated Outfile /home/lewis/tmp/images/blackbuck.bmp

 $ j2k_to_image -i /home/lewis/tmp/images/blackbuck.j2k -o /home/lewis/tmp/images/blackbuck.png
 $ j2k_to_image -i /home/lewis/tmp/images/blackbuck.j2k -o /home/lewis/tmp/images/blackbuck.ppm
 $ j2k_to_image -i /home/lewis/tmp/images/blackbuck.j2k -o /home/lewis/tmp/images/blackbuck.tif
all produced similar output and correct viewable images.

The update: Problem. In Updates Testing repository, I only see:
and NOT openjpeg-1.5.2-5.1.mga5, nor any other update with version 1.5.2-5.1 .
So I defer the update until advised. TIA
Comment 19 Lewis Smith 2016-10-22 22:48:39 CEST
Continue testing x64 real h/w

I found the reason for the preceding update problem. I normally have 32-bit repos enabled (because it is recommended), but do *not* normally enable these for Update Testing. I re-tried the update with 32-bit Core Updates Testing enabled in addition to the usual 64-bit Update Testing repos - and found the missing package. Plus libopenjpeg5 which I am usure if it matters.
I have never hit such a problem before. The apparent dependance on 32-bit repos is worrying.

AFTER the update:
Re-running the same pre-update commands:

 $ image_to_j2k -i tuesday-w2.bmp -o ~/tmp/images/tuesday-w2.j2k
 Error, unknown BMP header size 124
 Unable to load bmp file
Same erroneous outpat as before.

 $ image_to_j2k -i blackbuck.png -o ~/tmp/images/blackbuck.j2k
 $ image_to_j2k -i bell_206.ppm -o ~/tmp/images/bell_206.ppm.j2k
 $ image_to_j2k -i ElderChmpgn.tiff -o ~/tmp/images/ElderChmpgn.j2k
Results same as before: generated 3 jpeg200 images bell_206.ppm.j2k  blackbuck.j2k  ElderChmpgn.j2k, none of which were viewable by normal means, nor openable by Gimp; only Darktable (again) opened them.

 $ j2k_dump -i /home/lewis/tmp/images/bell_206.j2k
 $ j2k_dump -i /home/lewis/tmp/images/blackbuck.j2k
 $ j2k_dump -i /home/lewis/tmp/images/ElderChmpgn.j2k
As before, each file yielded sensible formatted output.

 $ j2k_to_image -i /home/lewis/tmp/images/blackbuck.j2k -o /home/lewis/tmp/images/blackbuck.bmp
 $ j2k_to_image -i /home/lewis/tmp/images/blackbuck.j2k -o /home/lewis/tmp/images/blackbuck.png
 $ j2k_to_image -i /home/lewis/tmp/images/blackbuck.j2k -o /home/lewis/tmp/images/blackbuck.ppm
 $ j2k_to_image -i /home/lewis/tmp/images/blackbuck.j2k -o /home/lewis/tmp/images/blackbuck.tif
As before, all produced correct viewable images.
So for these tests, the results are the same as before the update.

Installed KRITA to try - it pulls in very many packages if you do not already have Calligra.
Its 'open' file selection dialogue did not show .j2k images. It recognises files suffixed .jp2 .jpf .jpx. I re-named one of the .j2k files produced earlier to .jp2, but Krita could not open it (internal error).
Opening a normal .jpg file, and saving that as a JPEG2000 .jp2 image, worked. So did re-opening that image, EXCEPT that magnifying it showed that the result after 100% compression was poor. Re-trying another .jpg source image saved at 20% compression .jp2 was considerably better, but not seriously adequate. 0 compression would be best.

 $ j2k_dump -i /home/lewis/tmp/images/P1000784.jp2
worked, so openjpeg is happy with Krita's export. 

Installed MTPAINT to try. About 10x faster than Krita...
Its open dialogue shows all suffixes. It successfully opened the .j2k files produced by 'image_to_j2k', as well as the .jp2 ones exported from Krita. No matter how many jpeg2000 files are opened (one after another), it only calls this library *once*:
 $ strace -o tmp/mtpaint.txt mtpaint
 $ grep libopenjpeg tmp/mtpaint.txt
 open("/lib64/libopenjpeg.so.5", O_RDONLY|O_CLOEXEC) = 3
There is no facility here for saving as jpeg2000 - nor even straight JPEG!

Already shown that this opens .jk2 files ex 'image_to_j2k'. It also opens .jp2 files exported from Krita. Its own jpeg2000 exports, both .j2k and .jp2, were opened successully by Mtpaint.

Functionality with the applications above seems mostly OK; and specific command tests were the same pre & post update. Perhaps I should have removed openjpeg2 beforehand in case that was used instead; too late...

After all the work with this update, with no new ill effects, I am OKing it!
And validating at the same time.
Advisory to follow.

Keywords: (none) => validated_update
Whiteboard: has_procedure MGA5-32-OK => has_procedure MGA5-32-OK MGA5-64-OK
CC: (none) => sysadmin-bugs

Comment 20 Lewis Smith 2016-10-23 09:36:53 CEST
Advisory uploaded.

Whiteboard: has_procedure MGA5-32-OK MGA5-64-OK => has_procedure MGA5-32-OK MGA5-64-OK advisory

Comment 21 Mageia Robot 2016-10-23 10:50:31 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

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