SUSE has issued an advisory on March 22: http://lists.suse.com/pipermail/sle-security-updates/2019-March/005227.html Cauldron is probably not affected.
Assigning to all packagers collectively, since there is no registered maintainer for this package. Also CC'ing some submitters.
CC: (none) => joequant, marja11, mrambo, nicolas.salgueroAssignee: bugsquad => pkg-bugs
Suggested advisory: ======================== The updated packages fix a security vulnerability: get_8bit_row in rdbmp.c in libjpeg-turbo through 1.5.90 and MozJPEG through 3.3.1 allows attackers to cause a denial of service (heap-based buffer over-read and application crash) via a crafted 8-bit BMP in which one or more of the color indices is out of range for the number of palette entries. (CVE-2018-14498) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14498 http://lists.suse.com/pipermail/sle-security-updates/2019-March/005227.html ======================== Updated packages in core/updates_testing: ======================== lib(64)jpeg8-1.5.1-1.3.mga6 lib(64)jpeg62-1.5.1-1.3.mga6 lib(64)turbojpeg0-1.5.1-1.3.mga6 lib(64)jpeg-devel-1.5.1-1.3.mga6 lib(64)jpeg-static-devel-1.5.1-1.3.mga6 jpeg-progs-1.5.1-1.3.mga6 from SRPMS: libjpeg-1.5.1-1.3.mga6.src.rpm
Assignee: pkg-bugs => qa-bugsCVE: (none) => CVE-2018-14498Source RPM: libjpeg-1.5.1-1.mga6.src.rpm => libjpeg-1.5.1-1.2.mga6.src.rpmStatus: NEW => ASSIGNED
mga6, x86_64 CVE-2018-14498 https://github.com/libjpeg-turbo/libjpeg-turbo/issues/258 POC at: https://github.com/ntu-sec/pocs/tree/master/libjpeg-f4b8a5c $ cjpeg -outfile /dev/null 'hbo_rdbmp.c_210_1.bmp' Unrecognized input file format --- perhaps you need -targa $ cjpeg -outfile /dev/null 'hbo_rdbmp.c_209_1.bmp' Unrecognized input file format --- perhaps you need -targa $ cjpeg -targa -outfile /dev/null 'hbo_rdbmp.c_209_1.bmp' Invalid or unsupported Targa file <which is to be expected> Mangled the file name slightly: $ cjpeg -outfile /dev/null hbo_rdbm__c_209_2.bmp cjpeg: can't open hbo_rdbm__c_209_2.bmp $ cjpeg -outfile /dev/null hbo_rdbmp.c_211_1.bmp Unrecognized input file format --- perhaps you need -targa Suse at https://bugzilla.suse.com/show_bug.cgi?id=1128712&_ga=2.193600621.1959551290.1553634141-55335118.1500933662 $ valgrind cjpeg -outfile /dev/null hbo_rdbmp.c\:145_1.bmp Output differs from upstream because the POC file cannot be opened. This might indicate that our software had already been patched. $ cjpeg -outfile /dev/null hbo_rdbmp.c\:145_1.bmp cjpeg: can't open hbo_rdbmp.c:145_1.bmp $ cjpeg -outfile poc.jpg hbo_rdbmp_145_1.bmp $ file poc.jpg poc.jpg: JPEG image data, JFIF standard 1.01, resolution (DPCM), density 118x118, segment length 16, baseline, precision 8, 4x2, frames 3 $ eom poc.jpg Shows black pane and the information "4 x 2 pixels". display shows a tiny black rectangle. Ran the update. - jpeg-progs-1.5.1-1.3.mga6.x86_64 - lib64jpeg-devel-1.5.1-1.3.mga6.x86_64 - lib64jpeg62-1.5.1-1.3.mga6.x86_64 - lib64jpeg8-1.5.1-1.3.mga6.x86_64 - lib64turbojpeg0-1.5.1-1.3.mga6.x86_64 plus lib64jpeg-static-devel Ran some of the reproducers again for CVE-2018-14498. $ cjpeg -outfile /dev/null hbo_rdbmp__c_209_2.bmp Unrecognized input file format --- perhaps you need -targa $ cjpeg -outfile /dev/null hbo_rdbmp.c_211_1.bmp Unrecognized input file format --- perhaps you need -targa $ cjpeg -outfile /dev/null hbo_rdbmp_210_1.bmp Unrecognized input file format --- perhaps you need -targa All much the same except for the Suse test: $ cjpeg -outfile /dev/null hbo_rdbmp_145_1.bmp Numeric value out of range in BMP file The patch works. jpeg-progs comprises a few utilities for image conversion from and to JPEG. Used display to view the output images. In /bin: cjpeg, djpeg, jpegtran, rdjpgcom, wrjpgcom All these tests were successful but several were not because the utilities are finicky about input formats. cjpeg I think is looking for bitmap input without any compression. $ cjpeg -outfile test1.jpg piuva.ppm $ djpeg -outfile test2.bmp kappaCrucis.jpg $ cjpeg -grayscale -outfile test3.jpg lena.pnm $ cjpeg -quality 80 maple.tga > test4.jpg $ djpeg sunset.jpg > test5.bmp $ djpeg -verbose kappaCrucis.jpg > test6.jpg libjpeg-turbo version 1.5.1 (build 20190326) Copyright (C) 2009-2016 D. R. Commander Copyright (C) 2011-2016 Siarhei Siamashka [...] Emulating The Independent JPEG Group's software, version 8d 15-Jan-2012 Start of Image JFIF APP0 marker: version 1.01, density 400x400 1 Miscellaneous marker 0xed, length 8892 [...] Define Quantization Table 0 precision 0 Define Quantization Table 1 precision 0 Start Of Frame 0xc0: width=2552, height=1702, components=3 Component 1: 1hx1v q=0 [...] Define Huffman Table 0x11 Start Of Scan: 3 components Component 1: dc=0 ac=0 Component 2: dc=1 ac=1 Component 3: dc=1 ac=1 Ss=0, Se=63, Ah=0, Al=0 End Of Image $ jpegtran -rotate 180 Occator.jpg > test7.jpg $ jpegtran -optimize -progressive Occator.jpg > test8.jpg $ ll Occator.jpg test8.jpg -rw-r--r-- 1 lcl lcl 2189688 Mar 27 08:10 Occator.jpg -rw-r--r-- 1 lcl lcl 1857202 Mar 27 09:05 test8.jpg $ wrjpgcom -comment "This has been gimped" sunset.jpg > test9.jpg The output file displays the same as the input. $ rdjpgcom test9.jpg Adobe ImageReady This has been gimped This should do for an OK.
Whiteboard: (none) => MGA6-64-OKCC: (none) => tarazed25
Fedora has issued an advisory for this today (March 29): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/F7YP4QUEYGHI4Q7GIAVFVKWQ7DJMBYLU/
Severity: normal => major
MGA6, 32 bits Updated libjpeg8, open jpeg files in gimp and gwenview.
CC: (none) => lists.jjorgeWhiteboard: MGA6-64-OK => MGA6-64-OK MGA6-32-OK
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
CC: (none) => davidwhodginsKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0132.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED