[Podofo-users] Excessive Iteration in PdfParser::ReadObjectsInternal function (src/base/PdfParser.cpp)

2018-01-31 Thread Probe Fuzzer 
On latest release version (0.9.5) and master branch of podofo:
There is an Excessive Iteration in PdfParser::ReadObjectsInternal
function of file, which could be triggered by the POC below.

The issue happens since in PdfParser::ReadObjectsInternal function,
there is a while loop (line 1053), whose iteration times could be
manipulated by the input file. The POC file, which is only 98 bytes in
size, could make the "m_nNumObjects" variable a huge value (i.e.,
210041). It takes tens of minutes for podofo to handle this tiny
POC file.


   1046 void PdfParser::ReadObjectsInternal()
   1047 {
   1048 int  i= 0;
   1049 int  nLast= 0;
   1050 PdfParserObject* pObject  = NULL;
   1051
   1052 // Read objects
   1053 for( i=0; i < m_nNumObjects; i++ )
   1054 {
...
}

To trigger the issue, run: podofoimgextract $POC OUTPUT

The POC file could be downloaded at:
https://bugzilla.redhat.com/show_bug.cgi?id=1539237


 The backtrace is:
(gdb) bt
#0  0x0058a148 in std::_Deque_iterator::operator+=
(this=0x7fffcd40, __n=449699)
at /home/test/ProbeFuzzer/dep/gcc/exe/include/c++/5.4.0/bits/stl_deque.h:216
#1  0x00589bf9 in
std::__advance, long> (__i=...,
__n=449699)
at 
/home/test/ProbeFuzzer/dep/gcc/exe/include/c++/5.4.0/bits/stl_iterator_base_funcs.h:156
#2  0x00583c1f in
std::advance, long> (__i=...,
__n=449699)
at 
/home/test/ProbeFuzzer/dep/gcc/exe/include/c++/5.4.0/bits/stl_iterator_base_funcs.h:177
#3  0x0057c88d in
std::__equal_range, PoDoFo::PdfReference,
__gnu_cxx::__ops::_Iter_comp_val,
__gnu_cxx::__ops::_Val_comp_iter
> (__first=..., __last=..., __val=...,
__comp_it_val=..., __comp_val_it=...) at
/home/test/ProbeFuzzer/dep/gcc/exe/include/c++/5.4.0/bits/stl_algo.h:2140
#4  0x00578346 in
std::equal_range, PoDoFo::PdfReference,
PoDoFo::ReferenceComparatorPredicate> (__first=..., __last=...,
__val=..., __comp=...) at
/home/test/ProbeFuzzer/dep/gcc/exe/include/c++/5.4.0/bits/stl_algo.h:2237
#5  0x0056bef7 in PoDoFo::PdfVecObjects::AddFreeObject
(this=0x7fffd890, rReference=...)
at 
/u/test/ProbeFuzzer/product/podofo/patch/src/src/base/PdfVecObjects.cpp:256
#6  0x007c7913 in PoDoFo::PdfParser::ReadObjectsInternal
(this=0x6170fc80) at
/u/test/ProbeFuzzer/product/podofo/patch/src/src/base/PdfParser.cpp:1156
#7  0x007c395f in PoDoFo::PdfParser::ReadObjects
(this=0x6170fc80) at
/u/test/ProbeFuzzer/product/podofo/patch/src/src/base/PdfParser.cpp:1043
#8  0x007a842c in PoDoFo::PdfParser::ParseFile
(this=0x6170fc80, rDevice=..., bLoadOnDemand=true)
at /u/test/ProbeFuzzer/product/podofo/patch/src/src/base/PdfParser.cpp:220
#9  0x007a7a23 in PoDoFo::PdfParser::ParseFile
(this=0x6170fc80, pszFilename=0x7fffe12a "6.pdf",
bLoadOnDemand=true)
at /u/test/ProbeFuzzer/product/podofo/patch/src/src/base/PdfParser.cpp:166
#10 0x00645a00 in PoDoFo::PdfMemDocument::Load
(this=0x7fffd810, pszFilename=0x7fffe12a "6.pdf",
bForUpdate=false)
at 
/u/test/ProbeFuzzer/product/podofo/patch/src/src/doc/PdfMemDocument.cpp:256
#11 0x0063f545 in PoDoFo::PdfMemDocument::PdfMemDocument
(this=0x7fffd810, pszFilename=0x7fffe12a "6.pdf",
bForUpdate=false)
at 
/u/test/ProbeFuzzer/product/podofo/patch/src/src/doc/PdfMemDocument.cpp:102
#12 0x004bd761 in ImageExtractor::Init (this=0x7fffdaa0,
pszInput=0x7fffe12a "6.pdf", pszOutput=0x7fffe130 "/tmp/",
pnNum=0x7fffda60)
at 
/u/test/ProbeFuzzer/product/podofo/patch/src/tools/podofoimgextract/ImageExtractor.cpp:51
#13 0x004c5f5f in main (argc=3, argv=0x7fffddf8) at
/u/test/ProbeFuzzer/product/podofo/patch/src/tools/podofoimgextract/podofoimgextract.cpp:54
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Next PoDoFo Release 0.9.6

2018-01-31 Thread Michal Sudolsky 
Hello,

Recursion is at many places, not only in PdfParser, I have feeling
everywhere where is recursion in pdf structures like trees, for example
GetPageNode in PdfPagesTree. There is no problem to create small pdf with
too large depth, also this can be cycled via references and I am now not
sure whether is this treated. But what would be safe maximum recursion
depth, maybe 10-100? Maybe better would be to avoid it and use queues or
deques, heap is larger than stack and memory allocation fault can be
checked better than size of stack.


On Thu, Feb 1, 2018 at 12:46 AM, Matthew Brincke  wrote:

> [ grammar fix in quoted text ]
>
> Hello Dominik, hello all,
>
> Dominik Seichter  wrote on 27 January 2018,
> 13:23:
> >
> >
> > Hi Matthew et al.,
> >
> >
> > On Fri, Jan 26, 2018 at 11:35 PM, Matthew Brincke 
> wrote:
> >
> >> [ Left Dominik in To to help him follow this thread, fixed text typos ]
> >>
> >>  Hello Dominik, hello all,
> >>
> >>> Dominik Seichter via Podofo-users has written on 26 January 2018 at
> 17:37:
> >>>
> >>>
> >>> Hi Mattia,
> >>>
> >>> Thanks for the good summary! Let me comment on the open issues.
> >>>
> >>> Unfixed security issues:
> >>  ... snip ...
> >>>
> >>> https://security-tracker.debian.org/tracker/CVE-2017-8053
> >>> -> Please see proposed patch in attachment. Can somebody test/review?
> >>>
> >>
> >>  In line 13 of the patch, there are typos, it should be "already
> visited",
> >>  line 14 doesn't really fit (which object?), and in general, shouldn't
> >>  there be a maximum recursion depth which is checked for, to prevent a
> >>  stack overflow? AFAICS there is no standard function/method to check
> >>  available stack space ;-( ...
> >
> > Yes, typos fixed and line 14 removed. Also agreed, that a maximum check
> > might be nice. Still, the patch should address the main issue of being
> > vulnerable to certain PDF files.
>
> AIUI without a check for a maximum recursion depth files can be crafted,
> maximally some MiB large, which cause so deep recursion that the (default)
> stack size is exhausted and, therefore, a stack overflow occurs. For that
> reason, Dominik, please include the check in your fix for CVE-2017-8053.
>
> >
> > Best regards,
> >  Dominik
>
> Best regards, mabri
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Next PoDoFo Release 0.9.6

2018-01-31 Thread Matthew Brincke 
[ grammar fix in quoted text ]

Hello Dominik, hello all,

Dominik Seichter  wrote on 27 January 2018, 13:23:
>  
> 
> Hi Matthew et al.,
> 
> 
> On Fri, Jan 26, 2018 at 11:35 PM, Matthew Brincke  wrote: 
> 
>> [ Left Dominik in To to help him follow this thread, fixed text typos ] 
>>  
>>  Hello Dominik, hello all, 
>>  
>>> Dominik Seichter via Podofo-users has written on 26 January 2018 at 17:37: 
>>>
>>>
>>> Hi Mattia,
>>>  
>>> Thanks for the good summary! Let me comment on the open issues.
>>>  
>>> Unfixed security issues:
>>  ... snip ... 
>>> 
>>> https://security-tracker.debian.org/tracker/CVE-2017-8053
>>> -> Please see proposed patch in attachment. Can somebody test/review? 
>>> 
>>  
>>  In line 13 of the patch, there are typos, it should be "already visited", 
>>  line 14 doesn't really fit (which object?), and in general, shouldn't 
>>  there be a maximum recursion depth which is checked for, to prevent a 
>>  stack overflow? AFAICS there is no standard function/method to check 
>>  available stack space ;-( ...
>  
> Yes, typos fixed and line 14 removed. Also agreed, that a maximum check
> might be nice. Still, the patch should address the main issue of being
> vulnerable to certain PDF files.

AIUI without a check for a maximum recursion depth files can be crafted,
maximally some MiB large, which cause so deep recursion that the (default)
stack size is exhausted and, therefore, a stack overflow occurs. For that
reason, Dominik, please include the check in your fix for CVE-2017-8053.

>  
> Best regards,
>  Dominik

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users