Some security issues in jasper have been reported, and a patch is available that may fix some of them, but it does not completely apply cleanly: http://openwall.com/lists/oss-security/2015/08/21/4 Mageia 4 and Mageia 5 are also affected. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA5TOO, MGA4TOO
Another issue was also reported (CVE-2015-5221): http://openwall.com/lists/oss-security/2015/08/20/4 I don't know of any patch for this issue yet.
URL: (none) => http://lwn.net/Vulnerabilities/655645/
Summary: jasper new security issue CVE-2015-5203 => jasper new security issues CVE-2015-5203 and CVE-2015-5221
I found the patch for the first CVE and submitted patched version into cauldron but as there is no patch for the other CVE I only commited the patch for mga5 and didn't submit yet. Not sure what to do about it. Do we wait more or we split the bug and fix at least one security issue?
CC: (none) => mageiaHardware: i586 => AllWhiteboard: MGA5TOO, MGA4TOO => MGA5TOO
Sure, we could split it.
Still no patch for the other issue.
Another issue was reported and assigned CVE-2016-1867: http://openwall.com/lists/oss-security/2016/01/13/6
Summary: jasper new security issues CVE-2015-5203 and CVE-2015-5221 => jasper new security issues CVE-2015-5203, CVE-2015-5221, and CVE-2016-1867
(In reply to David Walser from comment #5) > Another issue was reported and assigned CVE-2016-1867: > http://openwall.com/lists/oss-security/2016/01/13/6 OpenSuSE has issued an advisory for this on January 24: http://lists.opensuse.org/opensuse-updates/2016-01/msg00077.html
CVE-2015-5221 moved to Bug 17622.
Version: Cauldron => 5Summary: jasper new security issues CVE-2015-5203, CVE-2015-5221, and CVE-2016-1867 => jasper new security issues CVE-2015-5203 and CVE-2016-1867Whiteboard: MGA5TOO => (none)
Patched packages uploaded for Mageia 5 and Cauldron. Testing procedure in: https://bugs.mageia.org/show_bug.cgi?id=14729 ======================== Updated jasper packages fix security vulnerabilities: A double-free issue in JasPer 1.900.1 in the jasper_image_stop_load() function can cause a denial of service if a specially crafted JPEG image is loaded (CVE-2015-5203). The jpc_pi_nextcprl function in JasPer 1.900.1 allows remote attackers to cause a denial of service (out-of-bounds read and application crash) via a crafted JPEG 2000 image (CVE-2016-1867). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5203 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1867 http://openwall.com/lists/oss-security/2015/08/21/4 http://openwall.com/lists/oss-security/2016/01/13/6 http://lists.opensuse.org/opensuse-updates/2016-01/msg00077.html ======================== Updated packages in core/updates_testing: ======================== jasper-1.900.1-20.1.mga5 libjasper1-1.900.1-20.1.mga5 libjasper-devel-1.900.1-20.1.mga5 libjasper-static-devel-1.900.1-20.1.mga5 from jasper-1.900.1-20.1.mga5.src.rpm
Assignee: bugsquad => qa-bugsWhiteboard: (none) => has_procedure
(In reply to David Walser from comment #6) > (In reply to David Walser from comment #5) > > Another issue was reported and assigned CVE-2016-1867: > > http://openwall.com/lists/oss-security/2016/01/13/6 > > OpenSuSE has issued an advisory for this on January 24: > http://lists.opensuse.org/opensuse-updates/2016-01/msg00077.html LWN reference for CVE-2016-1867: http://lwn.net/Vulnerabilities/673469/
mga5 x86_64 Mate From "urpmq -i jasper" JasPer is a software-based implementation of the codec specified in the emerging JPEG-2000 Part-1 standard (i.e., ISO/IEC 15444-1). This package contains tools for working with JPEG-2000 images. I could not find any evidence that ImageMagick uses jasper so concentrated on jasper itself. From jasper --help: The following formats are supported: mif My Image Format (MIF) pnm Portable Graymap/Pixmap (PNM) bmp Microsoft Bitmap (BMP) ras Sun Rasterfile (RAS) jp2 JPEG-2000 JP2 File Format Syntax (ISO/IEC 15444-1) jpc JPEG-2000 Code Stream Syntax (ISO/IEC 15444-1) jpg JPEG (ISO/IEC 10918-1) pgx JPEG-2000 VM Format (PGX) [lcl@vega ~/qa]$ jasper --input piuva.jpg --output piuva.bmp [lcl@vega ~/qa]$ jasper --input piuva.bmp --output piuva.jpg THE BMP FORMAT IS NOT FULLY SUPPORTED! THAT IS, THE JASPER SOFTWARE CANNOT DECODE ALL TYPES OF BMP DATA. IF YOU HAVE ANY PROBLEMS, PLEASE TRY CONVERTING YOUR IMAGE DATA TO THE PNM FORMAT, AND USING THIS FORMAT INSTEAD. [lcl@vega ~/qa]$ jasper --input piuva.jpg --output piuva.pnm [lcl@vega ~/qa]$ file piuva.pnm piuva.pnm: Netpbm PPM "rawbits" image data, size = 320 x 340 [lcl@vega ~/qa]$ jasper --input piuva.pnm --output Piuva.jpg [lcl@vega ~/qa]$ file Piuva.jpg Piuva.jpg: JPEG image data, JFIF standard 1.01 [lcl@vega ~/qa]$ jasper --input piuva.jpg --output piuva.jp2 [lcl@vega ~/qa]$ eom piuva.jp2 [lcl@vega ~/qa]$ file piuva.jp2 piuva.jp2: JPEG 2000 Part 1 (JP2) JPEG files also converted to jpc format but pgx failed. [lcl@vega ~/qa]$ jasper --input piuva.pnm --output piuva.pgx error: BMP format does not support color space error: cannot encode image [lcl@vega ~/qa]$ jasper --input piuva.jpg --output piuva.pgx error: BMP format does not support color space error: cannot encode image [lcl@vega ~/qa]$ jasper --input piuva.jpg --output piuva.ras All these formats can be displayed with eom, gqview, gwenview and display but only display can cope with Sun raster files. [lcl@vega ~/qa]$ file piuva.ras piuva.ras: Sun raster image data, 320 x 340, 24-bit, no colormap [lcl@vega ~/qa]$ convert piuva.jpg -quality 100 piuva.pgx [lcl@vega ~/qa]$ eom piuva.pgx # OK [lcl@vega ~/qa]$ display piuva.pgx # OK [lcl@vega ~/qa]$ gqview piuva.pgx ERROR:filedata.c:1101:file_data_new_group: assertion failed: (fd) Abort Converting from a valid pgx image to jpg works. [lcl@vega ~/qa]$ jasper --input piuva.pgx --output Piuva.jpg [lcl@vega ~/qa]$ eom Piuva.jpg # OK This is all pre-update and lacks a PoC. Installed the update candidates and ran some of these image conversion tests again. [lcl@vega ~/qa]$ jasper --input piuva.jpg --output piuva.jp2 [lcl@vega ~/qa]$ eom piuva.jp2 eom: jas_stream.c:1044: mem_write: Assertion `ret == cnt' failed. Abort [lcl@vega ~/qa]$ display piuva.jp2 # OK [lcl@vega ~/qa]$ jasper --input piuva.pgx --output Piuva.jpg [lcl@vega ~/qa]$ display Piuva.jpg # OK [lcl@vega ~/qa]$ eom Piuva.jpg # OK [lcl@vega ~/qa]$ jasper --input piuva.pnm --output Piuva.ras [lcl@vega ~/qa]$ display Piuva.ras # OK [lcl@vega ~/qa]$ jasper --input Piuva.ras --output Piuva.jpc [lcl@vega ~/qa]$ eom Piuva.jpc eom: jas_stream.c:1044: mem_write: Assertion `ret == cnt' failed. Abort [lcl@vega ~/qa]$ display Piuva.jpc # OK So, the conversions work and display via ImageMagick but some of them have issues in desktop viewers.
CC: (none) => tarazed25
As far as I can tell eom does not use jasper and as it has not been updated the error it finds must have something to do with the format of the jpc image, for instance, which implies that there might be a bug in the jasper update or its library. Whatever the problem is, it does not bother ImageMagick. But now the water is getting murkier. A pre-update jasper was used to convert a JPEG to jpc format on another machine. eom handled it fine but the same file copied to the test machine now also fails under eom though display is fine with it. A diff between the imported jpc file and the original on the test machine is zero. I just cannot figure this out.
The md5sum values for the original and imported jpc files are identical. I am inclined to brush this one under the carpet because the conversions all seem to succeed and no differences can be found between the files that display and those that do not (under eom). What do you think David?
I don't know what eom is. If you can open a JPEG 2000 file in a program that uses libjasper1, then it's OK to go.
Sorry, eom is Eye of Mate, a fork from Eye of GNOME (eog), a simple image viewer that uses libjpeg. I was concentrating on the conversion side and using a range of viewers to check the results. ImageMagick seems to be the most accommodating. The problem with eom seems to be tangential to the testing of jasper, hence the "sweep it under the carpet".
The Gimp is listed as one of the packages needing lib64jasper1, referred to as libjasper.so.1()(64bit). gimp fails on jpc and jp2 files. gimp piuva.jpc and gimp piuva.jp2 both return: file-jp2-load: jas_stream.c:1044: mem_write: Assertion `ret == cnt' failed. The same is true for eom. As a cross-check I converted the jpeg image to jpc and jp2 formats using ImageMagick (which relies on libjpeg) and ran eom on them. That returned the same jas_stream.c error. The internal functions in libjasper1 have the form jas_streamxxx so my interpretation of the failures is that libjasper1 cannot handle the JPEG 2000 format after the update. Not OK.
Did you verify that it did work before this update?
Yes, I checked most of the formats, including JPEG 2000 , using different viewers. No problems.
OK thanks, we'll have to figure out which patch did it.
Whiteboard: has_procedure => has_procedure feedback
Please try the build I just pushed without the CVE-2016-1867 patch.
Updated to -1.900.1-20.2 The following command succeeded in displaying the image: [lcl@vega ~/qa]$ gwenview piuva.jp2 gwenview(21053) Gwenview::LoadingDocumentImplPrivate::loadMetaInfo: QImageReader::read() using format hint "jpc" failed: "Unsupported image format" gwenview(21053) Gwenview::LoadingDocumentImplPrivate::loadMetaInfo: QImageReader::read() without format hint failed: "Unsupported image format" This one failed: [lcl@vega ~/qa]$ eom piuva.jp2 eom: jas_stream.c:1044: mem_write: Assertion `ret == cnt' failed. Abort [lcl@vega ~/qa]$ gwenview piuva.jp2 gwenview(21383) Gwenview::LoadingDocumentImplPrivate::loadMetaInfo: QImageReader::read() using format hint "jpc" failed: "Unsupported image format" gwenview(21383) Gwenview::LoadingDocumentImplPrivate::loadMetaInfo: QImageReader::read() without format hint failed: "Unsupported image format" gwenview(21383) Gwenview::LoadingDocumentImplPrivate::loadMetaInfo: QImageReader::read() using format hint "jpc" failed: "Unsupported image format" gwenview(21383) Gwenview::LoadingDocumentImplPrivate::loadMetaInfo: QImageReader::read() without format hint failed: "Unsupported image format" The image failed to display - showed a popup: Loading 'piuva.jpc' failed Loading meta information failed. ImageMagick's display had no problem with either format. On to .3 I guess?
Now I've re-enabled the CVE-2016-1867 patch and disabled CVE-2015-5203. Try that. I don't see how CVE-2015-5203's patch would break things though, it just changes some int's to size_t's.
Updated to *-1.900.1-20.3 and all looks fine apart from rendering via gwenview. gewnview is fine with .jp2 images but fails on .jpc as an unrecognized format, which may well be the case anyway. Don't know enough about gwenview to say. eom has no trouble with either. gqview shows thumbnails for all the formats apart from ras which it does not support. Thus the problem seems to be in the CVE-2015-5203 patch. Maybe a cut-and-paste error in the patch? Or a missing initialization somewhere? Just guessing.
I see from http://openwall.com/lists/oss-security/2016/01/13/6 that there is a poc.jp2 somewhere which leads to a segfault but I do not know how to get hold of it.
(In reply to Len Lawrence from comment #23) > I see from http://openwall.com/lists/oss-security/2016/01/13/6 that there is > a poc.jp2 somewhere which leads to a segfault but I do not know how to get > hold of it. Sorry about that. openwall filters attachments, so you have to go to seclists for that. Here it is: http://seclists.org/oss-sec/2016/q1/84
OK, thanks David. Command from the readme.txt file produced the expected segmentation fault message on a system with the *.1 packages: $ jasper -f poc.jp2 -F temp.bmp -t jp2 -T bmp Segmentation fault Running this with the *.3 packages trapped the fault and left an empty temporary bitmap file: $ jasper -f poc.jp2 -F temp.bmp -t jp2 -T bmp warning: trailing garbage in marker segment (6 bytes) I did obtain an strace but don't think it contains anything that isn't already known. Next step is to backtrack to *.2 is it, and use --downgrade?
Created attachment 7383 [details] Crafted JPEG 2000 file $ jasper -f poc.jp2 -F temp.bmp -t jp2 -T bmp Segmentation fault before update - warning message afterwards.
Created attachment 7384 [details] Information from upstream tests.
Rats. Referring to comment #25 the PoC was applied to the pre *.1 system, i.e. {jasper, lib64jasper1}-1.900.1-20.mga5 :;
Len, what's the verdict on the last build of jasper? Is it OK or not?
Looking at comment #26, the test showed that jasper has been fixed so it is OK with respect to CVE-2016-1867. Not sure what is going on when the CVE-2015-5203 patch is enabled.
OK, let's release the fix for CVE-2016-1867 now and deal with CVE-2015-5203 (now moved to Bug 17622) later. Advisory: ======================== Updated jasper packages fix security vulnerabilities: The jpc_pi_nextcprl function in JasPer 1.900.1 allows remote attackers to cause a denial of service (out-of-bounds read and application crash) via a crafted JPEG 2000 image (CVE-2016-1867). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1867 http://openwall.com/lists/oss-security/2016/01/13/6 http://lists.opensuse.org/opensuse-updates/2016-01/msg00077.html ======================== Updated packages in core/updates_testing: ======================== jasper-1.900.1-20.3.mga5 libjasper1-1.900.1-20.3.mga5 libjasper-devel-1.900.1-20.3.mga5 libjasper-static-devel-1.900.1-20.3.mga5 from jasper-1.900.1-20.3.mga5.src.rpm
URL: http://lwn.net/Vulnerabilities/655645/ => http://lwn.net/Vulnerabilities/673469/Summary: jasper new security issues CVE-2015-5203 and CVE-2016-1867 => jasper new security issue CVE-2016-1867Whiteboard: has_procedure feedback => has_procedure
Whiteboard: has_procedure => has_procedure MGA5-64-OK
Assuming that it is alright to go with one architecture, validating this.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Yep, thanks for the help Len!
Advisory uploaded.
Whiteboard: has_procedure MGA5-64-OK => has_procedure advisory MGA5-64-OK
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0059.html
Status: NEW => RESOLVEDResolution: (none) => FIXED