Three security issues fixed upstream in openjpeg2 have been announced today (August 28):
Upstream commits to fix the issues are linked in the messages above.
Mageia 5 and Mageia 6 are also affected.
Assigning to the registered maintainer.
CVE-2017-14039 and CVE-2017-1404 assigned:
openjpeg2: 3 more new security issues fixed upstream =>
openjpeg2: 3 more new security issues fixed upstream (CVE-2017-14039 and CVE-2017-1404)
openjpeg2: 3 more new security issues fixed upstream (CVE-2017-14039 and CVE-2017-1404) =>
openjpeg2 new security issues fixed upstream (CVE-2017-14039, CVE-2017-1404, CVE-2017-1415)
Fedora has issued an advisory for this on September 6:
CVE-2017-14164 assigned for incomplete fix for CVE-2017-14152 (so we needn't list CVE-2017-14164 in our advisory, but we need the fix for it from the message below):
openjpeg2 new security issues fixed upstream (CVE-2017-14039, CVE-2017-1404, CVE-2017-1415) =>
openjpeg2 new security issues fixed upstream (CVE-2017-14039, CVE-2017-1404, CVE-2017-1415, CVE-2017-14164)
openSUSE has issued an advisory for this today (October 10):
Sorry for the delay, I've had a lot of bugs@ notification backlog lately. I'll have a look asap.
CVE-2017-1415 were fixed in Bug 21572, so we do need to list CVE-2017-14164 in the advisory.
Updated openjpeg2 packages fix security vulnerabilities:
A heap-based buffer overflow was discovered in the opj_t2_encode_packet
function. The vulnerability caused an out-of-bounds write, which may have lead
to remote denial of service or possibly unspecified other impact
An invalid write access was discovered in bin/jp2/convert.c, triggering a crash
in the tgatoimage function. The vulnerability may have lead to remote denial of
service or possibly unspecified other impact (CVE-2017-14040).
A stack-based buffer overflow was discovered in the pgxtoimage function. The
vulnerability caused an out-of-bounds write, which may have lead to remote
denial of service or possibly remote code execution (CVE-2017-14041).
A size-validation issue was discovered in opj_j2k_write_sot. The vulnerability
caused an out-of-bounds write, which may have lead to remote DoS or possibly
remote code execution (CVE-2017-14164).
Updated packages in core/updates_testing:
openjpeg2 new security issues fixed upstream (CVE-2017-14039, CVE-2017-1404, CVE-2017-1415, CVE-2017-14164) =>
openjpeg2 new security issues fixed upstream (CVE-2017-14039, CVE-2017-1404, CVE-2017-14164)Assignee:
MGA6TOO, MGA5TOO =>
My 64-bit M5 KDE system has jasper installed by default. It does not currently have openjpeg2 installed. If I am to attempt a test of openjpeg, should I remove jasper, or is it OK if I have the two installed side-by-side?
Or would it be better if I left this one to someone else?
They are both primarily libraries, used by whichever applications use them, which is mutually exclusive. They live side by side just fine. They don't concern each other.
OK, then. I've installed it, and viewed a jp2 file with several apps, but I am unsure if openjpeg2 was used on any of them.
No regressions noted, but I am unsure if this test is good enough to give an OK for 64-bit.
"urpmq --whatrequires lib64openjp2_7" shows that this library is used by imagemagick, lib64gs9 (aka ghostscript), and mupdf on Mageia 5.
Used ImageMagick to view the jp2 image. No problems noted.
Giving it the OK for Mga5.
(In reply to Thomas Andrews from comment #11)
> OK, then. I've installed it, and viewed a jp2 file with several apps, but I
> am unsure if openjpeg2 was used on any of them.
To find out whether any particular library is used by an application, start it from the command line via 'strace'. Try
$ strace -h [for help; -o is the main thing]
If you use it without any output parameter, it spills tons of info on the console. You can direct this to a file with the -o option, then after closing the application, you can search this file with 'less' for important strings like "open" or the library name. I have found the following method avoids the need for a separate file:
$ strace <the command> 2>&1 | grep <whatever>
This limits normal console O/P to whatever you grep for. One complication with libraries is exactly how they will be logged - not necessarily like the pkg name.
Here is an example (display = ImageMagick):
$ strace display bell_206.jp2 2>&1 | grep libopenjp2
open("/lib64/libopenjp2.so.7", O_RDONLY|O_CLOEXEC) = 4
(Normally it is 3 at the end). The terminal '7' corresponds with the end of the pkg name: libopenjp2_7. All this shows is that the library is invoked, but it is all we can easily do.
This usage is rather important where libraries are involved, and do not have (as is sometimes the case) a related command-line program to drive them, often called xxx-utils. Perhaps this warrants a ML post?
If you run ldd on the binary executable and it shows the library, it's a guarantee it will open it (strace is useful to catch dlopen()'d libraries which ldd doesn't show). If urpmq --whatrequires on the library shows a package, it is most likely because ldd on one of the binaries in the package showed that it is linked to that library.
Installed in 64-bit Mga6, opened same jp2 image as in Comment 13.
No issues noted.
Giving this the Mga6 OK.
MGA5TOO MGA5-64-OK =>
MGA5TOO MGA5-64-OK MGA6-64-OK
Many thanks TJ for both releases. Validating.
An update for this issue has been pushed to the Mageia Updates repository.