Fedora has issued an advisory today (April 27): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/I4ZEBKAKN5LJYYF7ZALERVHHMBSTN2ET/ The RedHat bug links to the upstream commit that fixed the issue: https://bugzilla.redhat.com/show_bug.cgi?id=1566756
Whiteboard: (none) => MGA6TOO, MGA5TOO
Assigning to the registered maintainer. CC'ing two committers, in case the maintainer lacks time.
CC: (none) => cjw, marja11, smelrorAssignee: bugsquad => thierry.vignaud
Patched packages uploaded for Mageia 5, Mageia 6, and Cauldron. Advisory: ======================== Updated qpdf packages fix security vulnerability: A flaw was found in QPDF through 8.0.2. libqpdf.a mishandles certain "expected dictionary key but found non-name object" cases, allowing remote attackers to cause a denial of service (stack exhaustion), related to the QPDFObjectHandle and QPDF_Dictionary classes (CVE-2018-9918). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9918 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/I4ZEBKAKN5LJYYF7ZALERVHHMBSTN2ET/ ======================== Updated packages in core/updates_testing: ======================== qpdf-7.1.1-1.1.mga5 libqpdf18-7.1.1-1.1.mga5 libqpdf-devel-7.1.1-1.1.mga5 qpdf-doc-7.1.1-1.1.mga5 qpdf-7.1.1-1.1.mga6 libqpdf18-7.1.1-1.1.mga6 libqpdf-devel-7.1.1-1.1.mga6 qpdf-doc-7.1.1-1.1.mga6 from SRPMS: qpdf-7.1.1-1.1.mga5.src.rpm qpdf-7.1.1-1.1.mga6.src.rpm
Whiteboard: MGA6TOO, MGA5TOO => MGA5TOOAssignee: thierry.vignaud => qa-bugsCC: cjw, marja11, smelror => (none)Version: Cauldron => 6
PoC for CVE-2018-9918 at https://github.com/qpdf/qpdf/issues/202 Downloaded qpdflibsegfault.zip Investigating this for Mageia 6, x86_64 later.
CC: (none) => tarazed25
Created attachment 10132 [details] Demo program for the listed PoC This should be compiled for clang.
Mageia 6, x86_64 Might need some help here. The PoC procedure specifies clang++-6.0 which we do not have. Tried compiling with plain clang, which failed - we have 3.9.1. $ clang -L/usr/local/lib -lz -ljpeg -lqpdf -lpthread *.cc -g -o openpdf openpdf.cc:14:6: error: use of class template 'std::vector' requires template arguments std::vector pages = pdf.getAllPages(); ^ /bin/../lib/gcc/x86_64-mageia-linux-gnu/5.5.0/../../../../include/c++/5.5.0/bits/stl_vector.h:214:11: note: template is declared here class vector : protected _Vector_base<_Tp, _Alloc> ^ 1 error generated.
Tried again: $ clang -L/usr/lib64 -lz -ljpeg -lqpdf -lpthread *.cc -g -o openpdf openpdf.cc:14:6: error: use of class template 'std::vector' requires template arguments std::vector pages = pdf.getAllPages(); ^ /bin/../lib/gcc/x86_64-mageia-linux-gnu/5.5.0/../../../../include/c++/5.5.0/bits/stl_vector.h:214:11: note: template is declared here class vector : protected _Vector_base<_Tp, _Alloc> ^ 1 error generated.
Installing clang-devel did not help either. How do we tell if the STL is properly installed?
MGA5-32 on Dell Latitude D600 Xfce No installation issues Ref bug 22586 for quick tests: $ qpdf --help shows loads of options $ qpdf --show-npages kursustekstorig.pdf 84 which is correct $ qpdf --check kursustekstorig.pdf checking kursustekstorig.pdf PDF Version: 1.4 File is not encrypted File is not linearized No syntax or stream encoding errors found; the file may still contain errors that qpdf cannot detect ]$ qpdf --show-xref kursustekstorig.pdf 1/0: uncompressed; offset = 2027831 2/0: uncompressed; offset = 19 3/0: uncompressed; offset = 262 4/0: uncompressed; offset = 2027977 and more $ qpdf --show-pages kursustekstorig.pdf page 1: 1 0 R content: 2 0 R page 2: 4 0 R content: 5 0 R and more till page 84. Seems OK to me, leave Len the honor to do the difficult stuff and OK it.
CC: (none) => herman.viaene
Thanks a bunch Herman - struggling with this PoC. Used g++ to compile and saw a similar error. Both compilers insist that std:vector needs arguments. I know nothing about templates so have no clue about what the author could have left out. The original script started with an empty #include; maybe something was forgotten?
There are so many chained references in this that you end up guessing. Had a look at /usr/include/c++/5.5.0/bits/stl_vector.h but could not understand it except that it looks like 'pages' might need a "type" and an "allocator".
Created attachment 10135 [details] Demo program for the listed PoC Added indentation for readability.
Attachment 10132 is obsolete: 0 => 1
@Herman re comment 8. It looks like the PoC test cannot be run so your testing is fine. I shall do something similar. Adding the mga5 32-bit OK on your behalf. Shall try mga5 x86_64 later.
Whiteboard: MGA5TOO => MGA5TOO MGA5-32-OK
Installed the updates. $ qpdf --show-npages PythonCookbook_2.pdf 846 $ qpdf --check PythonCookbook_2.pdf checking PythonCookbook_2.pdf PDF Version: 1.6 File is not encrypted File is not linearized No syntax or stream encoding errors found; the file may still contain errors that qpdf cannot detect Used qpdf to copy a pdf to pdf. $ qpdf PythonCookbook_2.pdf test.pdf $ ll PythonCookbook_2.pdf test.pdf -rw-r--r-- 1 lcl lcl 4867002 Sep 26 2015 PythonCookbook_2.pdf -rw-r--r-- 1 lcl lcl 4683131 May 9 08:34 test.pdf Not quite the same as cp so some unecessary bits may have been trimmed. The output file renders perfectly in xpdf. $ qpdf --show-xref ModernTkinter.pdf produces a long list of internal cross-references: ..................... 3107/0: uncompressed; offset = 2283906 3108/0: uncompressed; offset = 2284173 3109/0: uncompressed; offset = 2290347 3110/0: uncompressed; offset = 2290614 3111/0: uncompressed; offset = 2299661 3112/0: uncompressed; offset = 2299759 3113/0: uncompressed; offset = 2299911 $ qpdf --show-pages --with-images Arc.pdf $ qpdf --show-pages --with-images Arc.pdf ................... page 126: 683 0 R images: /Im0: 757 0 R, 1526 x 1106 content: 684 0 R page 127: 690 0 R content: 693 0 R page 128: 699 0 R images: /Im0: 970 0 R, 2332 x 1755 content: 700 0 R Comparing with previous tests, no regressions. On second thoughts, does this need to be tested in mga5 x86_64 given Herman's OK for 32-bits?
Whiteboard: MGA5TOO MGA5-32-OK => MGA5TOO MGA5-32-OK MGA6-64-OK
(In reply to Len Lawrence from comment #13) > On second thoughts, does this need to be tested in mga5 x86_64 given > Herman's OK for 32-bits? No, we've covered both releases and both architectures. It can be validated.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
advisory added to svn
Keywords: (none) => advisoryCC: (none) => tmb
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0232.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED