Hi
VeraPDF enforces the 8,388,607 indirect object limit:
https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFA-Part-1-rules#rule-6112-7
This answer on Adobe.com expands on the reason for the limit:
https://forums.adobe.com/thread/1041350 (Adobe Reader can’t load files with
more than 8,388,607 indirect objects)
This patch just changes the default – a PoDoFo library user can accept the risk
of uncontrolled memory allocation and restore the previous max limit by calling
PoDoFo::PdfParser::SetMaxObjectCount( std::numeric_limits<long>::max() )
With the 8,388,607 object count limit the maximum number of entries in
m_offsets is 8,388,607 which uses this amount of memory for m_offsets:
32-bit: 8,388,607 * sizeof(PoDoFo::PdfParser::TXRefEntry) = 8,388,607 * 16 =
134 MB
64-bit: 8,388,607 * sizeof(PoDoFo::PdfParser::TXRefEntry) = 8,388,607 * 24 =
201 MB
With the current object count limit (2**31 on 32-bit systems and 2**63 on
64-bit systems) then the maximum number of entries in m_offsets is less than
this because m_offsets.max_size() = std::numeric_limits<size_t>::max() /
sizeof(PoDoFo::PdfParser::TXRefEntry) which is:
32-bit: std::numeric_limits<size_t>::max() /
sizeof(PoDoFo::PdfParser::TXRefEntry) = 2**32 / 16 = 268,435,456 (requires
entire 32-bit address space)
64-bit: std::numeric_limits<size_t>::max() /
sizeof(PoDoFo::PdfParser::TXRefEntry) = 2 **64 / 24 = 7.6 x 10e17 (requires
entire 64-bit address space)
Related: I don’t think PoDoFo checks the maximum number of objects when writing
so it can produce PDFs that Adobe Reader can’t read.
Best Regards
Mark
--
Mark Rogers - mark.rog...@powermapper.com<mailto:mark.rog...@powermapper.com>
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
Hello Mark, hello all,
> On 15 April 2018 at 22:06 Mark Rogers <mark.rogers@...> wrote:
>
>
> Hi
>
>
> Here’s a simple patch for CVE-2018-5296 – it reduces the limit returned
> by GetMaxObjectCount from std::numeric_limits::max() to 8,388,607 which
> is the limit for for the maximum number of indirect objects specified
> in Table C.1 in Appendix C.2 Architectural Limits in PDF 32000-1:2008
>
the standard says there the limits are 32-bit systems whereas PoDoFo
uses 64-bit types in many places, therefore I'm feeling a bit uneasy
with the patch: Can anyone please shed some more light on this issue?
>
> Best Regards
>
>
> Mark
>
Best regards, mabri
From: Mark Rogers <mark.rog...@powermapper.com>
Date: Sunday, 15 April 2018 at 21:06
To: "podofo-users@lists.sourceforge.net" <podofo-users@lists.sourceforge.net>
Subject: [Podofo-users] [PATCH] PoFoFo: fix CVE-2018-5296 by reducing limit in
s_nMaxObjects
Hi
Here’s a simple patch for CVE-2018-5296 – it reduces the limit returned by
GetMaxObjectCount from std::numeric_limits<long>::max() to 8,388,607 which is
the limit for for the maximum number of indirect objects specified in Table C.1
in Appendix C.2 Architectural Limits in PDF 32000-1:2008
Best Regards
Mark
--
Mark Rogers - mark.rog...@powermapper.com<mailto:mark.rog...@powermapper.com>
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
------------------------------------------------------------------------------
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
