openSUSE has issued an advisory today (September 30): https://lists.opensuse.org/opensuse-updates/2016-09/msg00109.html 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. Advisory: ======================== 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). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7445 https://lists.opensuse.org/opensuse-updates/2016-09/msg00109.html ======================== Updated packages in core/updates_testing: ======================== openjpeg-1.5.2-5.1.mga5 libopenjpeg5-1.5.2-5.1.mga5 libopenjpeg-devel-1.5.2-5.1.mga5 from openjpeg-1.5.2-5.1.mga5.src.rpm
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
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.
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.
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.
That is what I figured initially but could not find an openjpeg tool. Had better do some more research. Thanks.
Installed lib64openjpeg-devel which supplies j2k_dump and j2k_to_image.
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.
Tried yet another machine and verified that the strace output is virtually identical when running the PoC file through image_to_j2k.
Sorry, meant to add "both before and after the updates".
CC: (none) => mageiaWhiteboard: (none) => has_procedure
no egfault here, before and after the new package, only the "Unable to load pnm file" error.
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
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.
(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?
As usual, urpmq is your friend. urpmq --whatrequires libopenjpeg5, shows darktable, krita, and mtpaint, as well as a few other libraries.
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.
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.viaeneWhiteboard: has_procedure => has_procedure MGA5-32-OK
Prior to testing M5-64 openjpeg provides the following commands: â/usr/bin/image_to_j2k â/usr/bin/j2k_dump â/usr/bin/j2k_to_image Main applications using lib64openjpeg5 (copy of Comment 14): darktable, krita, mtpaint - and not to overlook openjpeg itself!
CC: (none) => lewyssmith
Testing Mageia 5 x64 real hardware BEFORE update: lib64openjpeg5-1.5.2-5.mga5 libopenjpeg5-1.5.2-5.mga5 [Do not know why this is here] openjpeg-1.5.2-5.mga5 $ 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. And: $ 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: lib64openjpeg5-1.5.2-5.1.mga5 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
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: lib64openjpeg5-1.5.2-5.1.mga5 libopenjpeg5-1.5.2-5.1.mga5 openjpeg-1.5.2-5.1.mga5 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! DARKTABLE 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_updateWhiteboard: has_procedure MGA5-32-OK => has_procedure MGA5-32-OK MGA5-64-OKCC: (none) => sysadmin-bugs
Advisory uploaded.
Whiteboard: has_procedure MGA5-32-OK MGA5-64-OK => has_procedure MGA5-32-OK MGA5-64-OK advisory
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0353.html
Status: NEW => RESOLVEDResolution: (none) => FIXED