[
https://issues.apache.org/jira/browse/PDFBOX-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131884#comment-18131884
]
Tilman Hausherr edited comment on PDFBOX-6289 at 10/25/26, 4:24 PM:
--------------------------------------------------------------------
There's a comment in {{SecurityHandler.decryptDictionary()}} that the /Contents
string is not to be decrypted and they aren't. However {{SecurityHandler}}
doesn't do a similar check for encryption, which seems highly suspicious 😬
The problem happens in COSWriter, the code below indirectly calls
{{SecurityHandler.encryptString()}} which does the encryption.
{code}
if(reachedSignature && COSName.CONTENTS.equals(entry.getKey()))
{
signatureOffset = getStandardOutput().getPos();
value.accept(this);
signatureLength = getStandardOutput().getPos()- signatureOffset;
}
{code}
was (Author: tilman):
There's a comment in {{SecurityHandler.decryptDictionary()}} that the /Contents
string is not to be decrypted and they aren't. However {{SecurityHandler}}
doesn't do a similar check for encryption, which seems highly suspicious 😬
> Incremental signing of an encrypted PDF leaves non-zero (encrypted) bytes in
> the /Contents padding
> --------------------------------------------------------------------------------------------------
>
> Key: PDFBOX-6289
> URL: https://issues.apache.org/jira/browse/PDFBOX-6289
> Project: PDFBox
> Issue Type: Bug
> Components: Signing
> Affects Versions: 3.0.8 PDFBox
> Environment: MacOs: 27.0.1 (26A434)
> Java: openjdk 17.0.20.1
> BouncyCastle: 1.70
> pdfsig: 26.10.0
> pyHanko: 0.31.0 (CLI 0.2.0)
> Reporter: John
> Priority: Major
> Attachments: TestSign.java, bentopdf-pdfbox.png,
> bentopdf-pyhanko.png, check-contents.sh, document-enc-signed-pdfbox.pdf,
> document-enc-signed-pyhanko.pdf, document-enc.pdf, sign_pyhanko.py
>
>
> When I sign a AES-encrypted pdf with addSignature() and saveIncremental(),the
> resulting pdf's signature itself is valid and even tools like pdfsig and
> pyhanko reports it as valid with the whole document covered. The CMS is
> parsed as proper DER with openssl asn1parse.
> But the issue is with the bytes after the CMS inside the `/Contents` are not
> zeros. When pdfbox is used the `/Contents` string is 32 bytes longer than the
> reserved size, which matches an AES-CBC IV plus one padding block, and the
> tail looks random. So it appears that the placeholder is encrypted when
> written, and my CMS only overwrites the first part of it. As far as I know,
> /Contents should not be encrypted.
> This would not be a issue with most readers but some strict validators reject
> this as `Invalid Signature`. One of which is BentoPDF which reports the
> signature as invalid and says "Signature /Contents is not a single DER object
> followed by zero padding" for the encrypted pdf signed with PDFBox
> (screenshot attached) but when the same encrypted pdf signed by pyhanko it
> accepts it and shows the signature details(BentoPDF does not need password to
> validate signatures).
> Comparison (shell check attached, output below):
> {code}
> (test_env) ➜ pdfbox-test sh check-contents.sh document-enc-signed-pdfbox.pdf
> document-enc-signed-pyhanko.pdf
> document-enc-signed-pdfbox.pdf: /Contents=16416 bytes, CMS=1827 bytes,
> tail=14589 bytes, non-zero hex chars in tail=27295
> document-enc-signed-pyhanko.pdf: /Contents=8192 bytes, CMS=1972 bytes,
> tail=6220 bytes, non-zero hex chars in tail=0
> (test_env) ➜ pdfbox-test
> {code}
> Related: PDFBOX-2729 (encrypted signing support). Also asked on Stack
> Overflow:
> https://stackoverflow.com/questions/80012295/incremental-signature-on-an-aes-encrypted-pdf-leaves-encrypted-bytes-in-the-con
> Reproducer attached (TestSign.java): it loads document-enc.pdf (password
> 1234), signs it and saves incrementally. Any RSA PKCS12 works for the key.
> Is there a supported way to keep the placeholder unencrypted, or is this a
> bug?
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
