+++ This bug was initially created as a clone of Bug #22586 +++ Multiple security issues fixed upstream in qpdf have been announced: http://openwall.com/lists/oss-security/2018/02/13/2 It looks like all but the first linked from the message above were fixed after the last snapshot that we updated to. Updated package uploaded for Mageia 5. Advisory: ======================== Updated qpdf packages fix security vulnerabilities: - Stack overflow due to endless recursion in QPDFTokenizer::resolveLiteral() - Another stack overflow / endless recursion in QPDFWriter::enqueueObject() - Stack out of bounds read in iterate_rc4() - heap out of bounds read (large) in Pl_Buffer::write - Hang due to a pdf xref loop: Also, the libjpeg package has been patched to provide pkgconfig files, so that cups-filters could be rebuilt against this qpdf update. References: http://openwall.com/lists/oss-security/2018/02/13/2 ======================== Updated packages in core/updates_testing: ======================== qpdf-7.1.1-1.mga5 libqpdf18-7.1.1-1.mga5 libqpdf-devel-7.1.1-1.mga5 qpdf-doc-7.1.1-1.mga5 libjpeg8-1.3.1-4.3.mga5 libjpeg62-1.3.1-4.3.mga5 libturbojpeg0-1.3.1-4.3.mga5 libjpeg-devel-1.3.1-4.3.mga5 libjpeg-static-devel-1.3.1-4.3.mga5 jpeg-progs-1.3.1-4.3.mga5 cups-filters-1.0.71-1.4.mga5 libcups-filters1-1.0.71-1.4.mga5 libcups-filters-devel-1.0.71-1.4.mga5 from SRPMS: qpdf-7.1.1-1.mga5.src.rpm libjpeg-1.3.1-4.3.mga5.src.rpm cups-filters-1.0.71-1.4.mga5.src.rpm
openSUSE has issued an advisory for this on February 19: https://lists.opensuse.org/opensuse-updates/2018-02/msg00056.html It provides CVEs for some of the issues. Please add the following to the references: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11624 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11625 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11626 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11627 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12595 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9208 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9209 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9210 https://lists.opensuse.org/opensuse-updates/2018-02/msg00056.html
Following up the references for this. POC tests to follow, tomorrow.
CC: (none) => tarazed25
Mageia 6 :: x86_64 POC links: CVE-2017-11624 http://somevulnsofadlab.blogspot.co.uk/2017/07/qpdfan-infinite-loop-in-libqpdf.html CVE-2017-11625 http://somevulnsofadlab.blogspot.co.uk/2017/07/qpdfan-infinite-loop-in-libqpdf_26.html CVE-2017-11626 http://somevulnsofadlab.blogspot.co.uk/2017/07/qpdfan-infinite-loop-in-libqpdf_65.html CVE-2017-11627 http://somevulnsofadlab.blogspot.co.uk/2017/07/qpdfan-infinite-loop-in-libqpdf_21.html CVE-2017-12595 https://bugzilla.suse.com/show_bug.cgi?id=1055960 CVE-2017-{9208,9209,9210} https://blogs.gentoo.org/ago/2017/05/21/qpdf-three-infinite-loop-in-libqpdf/ CVE-2017-11624: qpdf-infiniteloop_1 CVE-2017-11625: qpdf-infiniteloop_4 CVE-2017-11626: qpdf-infiniteloop_3 CVE-2017-11627: qpdf-infiniteloop_2 CVE-2017-12595: qpdf_poc_crash.pdf CVE-2017-9208: 00176-qpdf-infiniteloop1 CVE-2017-9209: 00177-pdf-infiniteloop2 CVE-2017-9210: 00177-qpdf-infiniteloop3 Tests all took this form: "qpdf <POC file> -" Before updates: Sample; CVE-2017-11624: $ qpdf qpdf-infiniteloop_1 - WARNING: qpdf-infiniteloop_1: can't find PDF header WARNING: qpdf-infiniteloop_1: file is damaged WARNING: qpdf-infiniteloop_1: can't find startxref WARNING: qpdf-infiniteloop_1: Attempting to reconstruct cross-reference table qpdf-infiniteloop_1: unable to find trailer dictionary while recovering damaged file The next three showed the same output, then; CVE-2017-12595: $ qpdf qpdf_poc_crash.pdf - WARNING: qpdf_poc_crash.pdf: file is damaged WARNING: qpdf_poc_crash.pdf: can't find startxref WARNING: qpdf_poc_crash.pdf: Attempting to reconstruct cross-reference table Segmentation fault The last three showed the infiniteloop output, as above. Updated the packages. These were offered at MageiaUpdate: - jpeg-progs-1.3.1-4.3.mga5.x86_64 - lib64jpeg-devel-1.3.1-4.3.mga5.x86_64 - lib64jpeg-static-devel-1.3.1-4.3.mga5.x86_64 - lib64jpeg62-1.3.1-4.3.mga5.x86_64 - lib64jpeg8-1.3.1-4.3.mga5.x86_64 - lib64qpdf-devel-7.1.1-1.mga5.x86_64 - lib64qpdf18-7.1.1-1.mga5.x86_64 - lib64turbojpeg0-1.3.1-4.3.mga5.x86_64 - qpdf-7.1.1-1.mga5.x86_64 - qpdf-doc-7.1.1-1.mga5.noarch - cups-filters-1.0.71-1.4.mga5.x86_64 - lib64cups-filters-devel-1.0.71-1.4.mga5.x86_64 - lib64cups-filters1-1.0.71-1.4.mga5.x86_64 After updates: All the infiniteloop tests showed the same output as before - an indication that the patches had already been applied (https://bugs.mageia.org/show_bug.cgi?id=22586). $ qpdf qpdf_poc_crash.pdf - WARNING: qpdf_poc_crash.pdf: file is damaged WARNING: qpdf_poc_crash.pdf: can't find startxref WARNING: qpdf_poc_crash.pdf: Attempting to reconstruct cross-reference table WARNING: qpdf_poc_crash.pdf (trailer, file position 20728): unknown token while reading object; treating as string qpdf_poc_crash.pdf (trailer, file position 20732): EOF while reading token This is the new issue and the output shows that the crash has been avoided. Looks like a clean bill of health. Shall look at the libjpeg and cups-filters stuff later.
I was able to print a document with these updates, OK'ing for Mageia 5 x86_64.
Whiteboard: (none) => MGA5-64-OK
Continuing from comment 3:- jpeg-progs supplies the utilities: cjpeg djpeg jpegtran rdjpgcon wrjpgcon Insert comment in a JPEG file. The resulting image displays fine. $ wrjpgcom -comment "Tarantula nebula from HST" tarantula2_hst.jpg > Tarantula.jpg $ display Tarantula.jpg The image looked the same as the original. $ strings Tarantula.jpg | grep HST Tarantula nebula from HST $ rdjpgcom Tarantula.jpg Tarantula nebula from HST Used strace to examine the operation. The only library that is used is libc and most of the action looks like a binary copy of the image to stdout. No idea how the comment string is inserted. Compress/convert original image. $ cjpeg -quality 90 hori.tga > bar.jpg $ eom bar.jpg Showed a horizontal coloured bar identical to the original. Decompress JPEG file. $ djpeg -gif bar.jpg > bar.gif $ eom bar.gif The GIF image looked identical to bar.jpg. $ jpegtran -transpose OrionBelt.jpg > orion.jpg $ display orion.jpg The resulting image had been rotated 90° clockwise and flipped from left to right which I think is the expected behaviour. The rotate and flip options were not tried because of a warning that they behave oddly if the image dimensions are not multiples of 8 or 16. Greyscale conversion worked perfectly. $ jpegtran -grayscale OrionBelt.jpg > orion_grey.jpg A trace shows the use of libjpeg. $ cat trace | grep jpeg execve("/usr/bin/jpegtran", ["jpegtran", "-grayscale", "OrionBeltx_demartin.jpg"], [/* 76 vars */]) = 0 open("/lib64/libjpeg.so.8", O_RDONLY|O_CLOEXEC) = 3 Printed a PDF file using lpr and ran a trace on it which showed libcups being used but was unable to see if cups-filters was involved. The Linux Printing wiki for cups-filters has this to say: This project provides backends, filters, and other software that was once part of the core CUPS distribution but is no longer maintained by Apple Inc. In addition it contains additional filters and software developed independently of Apple, especially filters for the PDF-centric printing workflow introduced by OpenPrinting .............. In general the update looks fine for 64-bit.
Correction to comment 3. All these tests were run on Mageia 5, not 6. Sorry about that. Too late in the day when I started.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
advisory uploaded
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0145.html
Status: NEW => RESOLVEDResolution: (none) => FIXED