Hi, there is a stack buffer overflow at src/base/PdfDictionary.cpp:65:
Poc is attach below.
the stack trace is shown following:
$ ./podofopdfinfo poc
Document Info
-------------
File: unique-crashes/id:000028,sig:11,src:000039,op:flip1,pos:4920
PDF Version: 1.7
Page Count: 1
Page Size: 500 x 500 pts
Fast Web View Enabled: No
Tagged: No
Encrypted: No
Printing Allowed: Yes
Modification Allowed: Yes
Copy&Paste Allowed: Yes
Add/Modify Annotations Allowed: Yes
Fill&Sign Allowed: Yes
Accessibility Allowed: Yes
Document Assembly Allowed: Yes
High Quality Print Allowed: Yes
Classic Metadata
----------------
Author:
Creator:
Subject:
Title:
Keywords:
Trapped:
Page Info
---------
Page Count: 1
Page 0:
->Internal Number:1
->Object Number:14 0 R
MediaBox: [ 0.000000 0.000000 500.000000 500.000000 ]
Rotation: 0
# of Annotations: 1
Annotation 0
Type: 19
Contents:
Title: Button
Flags: 4
Rect: [ 31.937100 416.754000 86.910800 469.634000 ]
Open: false
Outlines
--------
==111394==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc3b485ef8 (pc 0x00000056d626 bp 0x7ffc3b486770 sp 0x7ffc3b485f00 T0)
#0 0x56d625 in __asan_memcpy /home/wdw/llvm-4.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors.cc:453
#1 0x5cd252 in PoDoFo::PdfDictionary::operator=(PoDoFo::PdfDictionary const&) /home/lt/vuln-fuzz/program/podofo-r1974/src/base/PdfDictionary.cpp:65:5
#2 0x5ccfd5 in PoDoFo::PdfDictionary::PdfDictionary(PoDoFo::PdfDictionary const&) /home/lt/vuln-fuzz/program/podofo-r1974/src/base/PdfDictionary.cpp:49:11
#3 0x61e2e2 in PoDoFo::PdfVariant::PdfVariant(PoDoFo::PdfDictionary const&) /home/lt/vuln-fuzz/program/podofo-r1974/src/base/PdfVariant.cpp:151:24
#4 0x5eb854 in PoDoFo::PdfObject::PdfObject(PoDoFo::PdfReference const&, char const*) /home/lt/vuln-fuzz/program/podofo-r1974/src/base/PdfObject.cpp:61:7
#5 0x62511c in PoDoFo::PdfVecObjects::GetObject(PoDoFo::PdfReference const&) const /home/lt/vuln-fuzz/program/podofo-r1974/src/base/PdfVecObjects.cpp:155:15
#6 0x6cf921 in PoDoFo::PdfOutlineItem::PdfOutlineItem(PoDoFo::PdfObject*, PoDoFo::PdfOutlineItem*, PoDoFo::PdfOutlineItem*) /home/lt/vuln-fuzz/program/podofo-r1974/src/doc/PdfOutlines.cpp:88:48
....
#245 0x6cf970 in PoDoFo::PdfOutlineItem::PdfOutlineItem(PoDoFo::PdfObject*, PoDoFo::PdfOutlineItem*, PoDoFo::PdfOutlineItem*) /home/lt/vuln-fuzz/program/podofo-r1974/src/doc/PdfOutlines.cpp:90:24
#246 0x6cf970 in PoDoFo::PdfOutlineItem::PdfOutlineItem(PoDoFo::PdfObject*, PoDoFo::PdfOutlineItem*, PoDoFo::PdfOutlineItem*) /home/lt/vuln-fuzz/program/podofo-r1974/src/doc/PdfOutlines.cpp:90:24
#247 0x6cf970 in PoDoFo::PdfOutlineItem::PdfOutlineItem(PoDoFo::PdfObject*, PoDoFo::PdfOutlineItem*, PoDoFo::PdfOutlineItem*) /home/lt/vuln-fuzz/program/podofo-r1974/src/doc/PdfOutlines.cpp:90:24
#248 0x6cf970 in PoDoFo::PdfOutlineItem::PdfOutlineItem(PoDoFo::PdfObject*, PoDoFo::PdfOutlineItem*, PoDoFo::PdfOutlineItem*) /home/lt/vuln-fuzz/program/podofo-r1974/src/doc/PdfOutlines.cpp:90:24
#249 0x6cf970 in PoDoFo::PdfOutlineItem::PdfOutlineItem(PoDoFo::PdfObject*, PoDoFo::PdfOutlineItem*, PoDoFo::PdfOutlineItem*) /home/lt/vuln-fuzz/program/podofo-r1974/src/doc/PdfOutlines.cpp:90:24
#250 0x6cf970 in PoDoFo::PdfOutlineItem::PdfOutlineItem(PoDoFo::PdfObject*, PoDoFo::PdfOutlineItem*, PoDoFo::PdfOutlineItem*) /home/lt/vuln-fuzz/program/podofo-r1974/src/doc/PdfOutlines.cpp:90:24
SUMMARY: AddressSanitizer: stack-overflow /home/wdw/llvm-4.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors.cc:453 in __asan_memcpy
==111394==ABORTING
As the constructor
PoDoFo::PdfOutlineItem::PdfOutlineItem(PoDoFo::PdfObject*, PoDoFo::PdfOutlineItem*, PoDoFo::PdfOutlineItem*)is the culprit also in issue #25, this very much looks like a duplicate of that one. This has just two calls more in its backtrace before it was intercepted, which is unlikely to be a material difference (important for fixing the issue), IMHO, so I'd like to close this, what do you think?Last edit: Matthew Brincke 2019-05-26
The problem with this file is a recursive outline structure, leading to infinite recursion in the PdfOutlineItem constructor: Following the
/Nextchain from16 0 objgets us to19 0 R,21 0 R,20 0 R, back to16 0 R.That is probably invalid (the pdf spec does not seem to explicitly say so, but it implies the chain of
/Nextshould terminate), but thePdfOutlineItemconstructor for20 0 Rdoesn't know that alleged next entry already came earlier.Issue #25 is the same problem with
/Firstentries a few lines higher. I don't think closing either one before a fix is integrated is a great idea, as they are security issues.For cross-reference, this has been assigned CVE-2020-18971