0

I'm having some difficulties with the pdf-library IText. The short story: the application used the library itext-2.0.8 in combination with core-renderer-R8 to create pdfs. The both libraries had to be updated, because of vulnerabilities. I successfully updated these libraries to itextpdf-5.5.13.2 and resp. to flying-saucer-pdf-itext5. It seems there is another problem with itextpdf-5.5.13.2: iTextPDF in iText before 7.1.17 allows command injection via a CompareTool filename that is mishandled on the gs (aka Ghostscript) command line in GhostscriptHelper.java.
you'll notice if you automatically build the application with Jenkins.

Should I update to itext7-core ?

It seems, that itext7-core is not compatible with itextpdf-5.5.13.2, so I can't use flying-saucer-pdf-itext5 anymore.

Is there any other option (beside rewriting the code of the application) ?

Thanx for any advice.

awgold90
  • 72
  • 13
  • Does your program use the CompareTool or the `GhostscriptHelper` class? If not then you're not subject to this weakness. – mkl Jan 13 '22 at 18:51
  • 2
    And are you aware that the license changed? So from version 2.X to 5.5 the license changed from LGPL/MGPL -> AGPL. So you now have to either buy a license or open source your whole project as AGPL. – Lonzak Jan 14 '22 at 07:53
  • My code doesn't use the class GhostscriptHelper, but the thing is, we have a policy. So if Jenkins reports a vulnerability in any of the dependencies, the dependency has to be replaced, regardless whether the class is used or not. Thanx for the hint with the license :-) – awgold90 Jan 14 '22 at 09:12
  • 1
    You are welcome. What vulnerabilities were reported in iText 2.0.8? The successor of this version is [openPDF](https://github.com/LibrePDF/OpenPDF). So one possibility would to use that library... – Lonzak Jan 14 '22 at 11:44
  • 1
    the successor to iText 2.0.8 is [iText 5](https://itextpdf.com/en/products/itext-5-legacy) (after iText 2.1.7), and the successor to iText 5 is [iText 7](https://itextpdf.com/en/products/itext-7/itext-7-core). – André Lemos Jan 14 '22 at 15:21
  • @Lonzak If I remember correctly the Problem with [Itext was](https://www.cvedetails.com/cve/CVE-2017-9096/) and one of its dependency, [bcprov](https://mvnrepository.com/artifact/org.bouncycastle/bcprov-jdk14), was also not free of problems. – awgold90 Jan 14 '22 at 15:22
  • 1
    Ps.: on the Ghostscript CVE comment, a 5.5.13.3 release will come out very soon (Feb 1st) to address that, but there are very few cases where that has an actual impact – André Lemos Jan 14 '22 at 16:07
  • @andré-lemos Thanx for the info. Unfortunately we have to use another library instead of itextpdf (because of the license). – awgold90 Jan 14 '22 at 17:19
  • @awgold90 then just update bouncy castle. (it should be compatible up-to 1.46). And the question is what you are doing with it: if you are not signing you might not need it? – Lonzak Jan 14 '22 at 18:23
  • 1
    *"but the thing is, we have a policy. So if Jenkins reports a vulnerability in any of the dependencies, the dependency has to be replaced, regardless whether the class is used or not"* - if you have such a strict policy, you should not at the same time use ancient library versions, is pretty clear that eventually some weakness in them will be found. Also such a strict policy will allow competitors to outmaneuver you by looking for issues in the libraries you use... – mkl Jan 19 '22 at 06:29

1 Answers1

-1

I switched back to Itext-2.1.7 . It worked (compile + runtime). However, the library bcprov-jdk14-1.38.jar was used AND THIS CAUSED a problem in Jenkins:

In Bouncy Castle JCE Provider version 1.55 and earlier the DSA does not fully validate ASN.1 encoding of signature on verification. It is possible to inject extra elements in the sequence making up the signature and still have it validate, which in some cases may allow the introduction of 'invisible' data into a signed structure.

After I explicitly excluded this library, I was able to compile, BUT there was a runtime error, even if I included a newer version of bcprov:

NoClassDefFoundError: org/bouncycastle/asn1/DEREncodable

This was caused by calling the function PdfEncryptor.encrypt().

The stack trace:

at com.lowagie.text.pdf.PdfEncryption.<init>(Unknown Source)
at com.lowagie.text.pdf.PdfWriter.setEncryption(Unknown Source)
at com.lowagie.text.pdf.PdfStamper.setEncryption(Unknown Source)
at com.lowagie.text.pdf.PdfEncryptor.encrypt(Unknown Source)

Is it possible to replace just only PdfEncryptor.encrypt() with something else? (maybe from the OpenPDF package ?)

awgold90
  • 72
  • 13
  • Well, first off all that BC issue is no issue at all for you; PDF is a format that allows to add 'invisible' data in a myriad places. Furthermore, do you create signatures in your code at all? Your focus on the `PdfEncryptor` appears to indicate that you merely encrypt. – mkl Jan 19 '22 at 06:35
  • Yes you're right. I just encrypt and set some "flags" on the generated PDF, e.g: "ALLOW_COPY", "ALLOW_PRINTING", ... This is the code: `PdfEncryptor.encrypt(new PdfReader(baosPdf.toByteArray()), baosPdfProtected, (userPassword != null ? userPassword.getBytes() : null), ownerPassword.getBytes(), PdfWriter.ALLOW_ASSEMBLY | PdfWriter.ALLOW_COPY | PdfWriter.ALLOW_PRINTING | PdfWriter.ALLOW_SCREENREADERS, true);`. – awgold90 Jan 19 '22 at 10:44
  • 1
    In other words you are not subject to the issue. If you want to update BC anyways, you need to patch your iText's encryption related code to get along with the current BC. – mkl Jan 19 '22 at 10:57