[Podofo-users] Untracked CVE issues now fixed (was: Re: CVE confusion, also in Debian (was: Re: Next PoDoFo Release 0.9.6))

[Matthew Brincke]

Hello all,

the CVE entries referenced below are now fixed in svn r1937.
These are CVE-2017-738[1-3].
URL: https://sourceforge.net/p/podofo/code/1937/

This means also: the Debian security tracker should be updated
(the "fixed versions" there didn't fix it AFAIK).

Best regards, mabri

> On 14 June 2018 at 01:37 Matthew Brincke  wrote:
> 
>
... snip ... 
> For the new info, please see my addition below (bad news).
> > On 12 June 2018 at 22:21 Matthew Brincke  wrote:
> > 
> > 
> > Hello Mattia, hello all,
> > > On 12 June 2018 at 16:25 Mattia Rizzolo  wrote:
> > > 
> > > 
> 
...snip...
> Upon detailed inspection, which I mostly did yesterday (Wednesday) like I
> promised, I found the claim in DLA-968-1's d/patches/CVE-2017-7380.patch
> that it also fixes CVE-2017-7381 to CVE-2017-7383 to be very suspect, if
> not outright mistaken.
> For CVE-2017-7381: If m_pResources in src/doc/PdfPage.cpp:609 is NULL,
> i.e. the page doesn't have resources, not even inherited ones (for those,
> cf. src/doc/PdfPage.cpp:63 to the end of the constructor), dereferencing
> it to call a method is undefined behaviour (likely crash/vulnerability).
> The patch doesn't change that, so it doesn't fix this CVE AFAICS.
> 
> For CVE-2017-7382: If the dictionary which is the value of/referred to
> by the /Font entry in the /Resources dictionary exists, the patch changes
> again nothing AFAICS (is the CVE ID bound to the specific reproducer?) so
> such a /Font dictionary without /Subtype entry (in the report, queried at
> src/doc/PdfFontFactory.cpp:200) can still trigger the bug (AFAICS, untested).
> 
> For CVE-2017-7383: The same except for /Type (in the report, queried at
> src/doc/PdfFontFactory.cpp:195) instead of /Subtype makes this unfixed.
> 
> > > 
> > > And if this is really going to reopen a CVE for stretch I'd need to
> > > check with the security team if they need/want to do something extra as
> > > well.
> > > 
> > Please do, thank you.
> > 
> > > -- 
> > > regards,
> > >  Mattia Rizzolo
> > > 
> > 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

[Podofo-users] PdfPagesTree::GetPageNode() - Why does it handle nested arrays?

[A. Massad]

Hi,

The current implementation of PdfPagesTree::GetPageNode() has a questionable 
branch for nested kids arrays:

// We have to traverse the tree
while( it != rKidsArray.end() )
{
if( (*it).IsArray() )
{ // Fixes PDFs broken by having trees with arrays nested once
...
}

Does anyone know what the relevance of nested kids arrays is??? Where do such 
broken PDFs occur and why should they be handled by PoDoFo? This is not in 
accordance with the PDF spec. And I have not found a single PDF tool (including 
Adobe products) which handles such broken PDFs, yet.

I think this case is meant to handle PDFs containing /Pages nodes of this form:

3 0 obj<>
endobj

However, if there is no really good reason for it, this branch should be 
completely removed from GetPageNode() to open the way for further improvements 
of the current code.

Best regards,
Amin


signature.asc
Description: Message signed with OpenPGP
--
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