[
https://issues.apache.org/jira/browse/PDFBOX-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238272#comment-17238272
]
Michael Klink commented on PDFBOX-5026:
---------------------------------------
The PDF simply is broken, isn't it? Thus, this is not a PDFBox _bug_, let alone
a _major_ one, the bug is in the producer of that file.
And "fixing" this, i.e. making PDFBox take information from a wrong trailer, is
making PDFBox an easier target for Shadow-Attack-like forgery.
Admittedly, the pull request only adds this behavior in case of {{isLenient()}}.
----
[~cholmes5324], is it known how this buggy PDF came into being? Is it a regular
output of some somewhat widely used program? Or is it possible that it has been
fabricated to make people implement leniency in PDF processors to later abuse
for forgery?
> Trailer validation fails when Pages cannot be found in the current trailer
> --------------------------------------------------------------------------
>
> Key: PDFBOX-5026
> URL: https://issues.apache.org/jira/browse/PDFBOX-5026
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 2.0.21
> Reporter: Cody Wayne Holmes
> Priority: Major
> Attachments: issue9418.pdf
>
>
> I am seeing an issue where multiple trailers exist for a PDF, but the trailer
> that is being found does not contain a Pages object in the Root.
> The PDF does have a trailer that can be read with Pages in the root but the
> brute force approach needs to be taken when parsing is lenient.
> This issue can be seen as being resolved in pdf.js here
> [https://github.com/mozilla/pdf.js/commit/56e3648b656bed1bf4ff52aa3cd70e8a8e53b56f]
> And sample pdf:
> https://github.com/mozilla/pdf.js/blob/master/test/pdfs/issue9418.pdf
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
