HIGH Security Vulnerability in hapi-fhir-test-utilities

[joepaquette]

hapi-fhir-test-utilities has a dependency on net.sourceforge.htmlunit which has a dependency on xalan:xalan.

xalan:xalan:2.7.2 has a HIGH security vulnerability and was last updated on July 24, 2014. see

Results from a WHITESOURCE security scan:

• Artifact ID: xalan
• Group ID: xalan
• Library Version: 2.7.2
• Library Path: /root/.gradle/caches/modules-2/files-2.1/xalan/xalan/2.7.2/d55d3f02a56ec4c25695fe67e1334ff8c2ecea23/xalan-2.7.2.jar
• Type: MAVEN_ARTIFACT
• Description: The Apache Xalan Java XSLT library is vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. This can be used to corrupt Java class files generated by the internal XSLTC compiler and execute arbitrary Java bytecode. The Apache Xalan Java project is dormant and in the process of being retired. No future releases of Apache Xalan Java to address this issue are expected. Note: Java runtimes (such as OpenJDK) include repackaged copies of Xalan.
• Suggested Fix: No suggested fix

[tadgh]

Heya! Greatly appreciate the report. The test utilities are test-scoped, and not shipped in production code. Since there seems to be no remediation immediately available, do you have any recommendations? Do you think it would be safe to just remove the dependency?

[joepaquette]

Someone should look at hapi-fhir-server-openapi because the test utilities are not scoped to test only. That's how we stumbled onto this issue. I'll add a new issue to resolve this.

The scanning tool we use apparently does not make distinctions between "test" and "production" dependencies, so we cannot make use of the test utilities package in our project.

Since the test utilities has a dependency on HtmlUnit and HtmlUnit has the dependency on Xalan, the only thing I can think of is to find an alternative to HtmlUnit that does not contain a dependency on Xalan. I'm not familiar with these tools, but a quick Google search (htmlunit alternative java) identified https://github.com/dhamaniasad/HeadlessBrowsers with numerous suggestions.

[jamesagnew]

Whoops! That is definitely an oversight, that should be a test scoped dep for sure.

[tadgh]

I'll submit a patch to to fix this for 6.1.0

…

On Mon, Aug 8, 2022, 7:30 AM James Agnew ***@***.***> wrote: Whoops! That is definitely an oversight, that should be a test scoped dep for sure. — Reply to this email directly, view it on GitHub <#3885 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANEA4JRSBXOOALB7GSG6FTVYEKWXANCNFSM55XISJVQ> . You are receiving this because you commented.Message ID: ***@***.***>

[jamesagnew]

FWIW I'd say let's just fix the scoping and that should be sufficient. We don't do any XSLT processing as a part of our build/test process so there is no risk of this being exploitable with that scope.

[jbonzohln]

This is fixed by #4306 if someone could review.

[tadgh]

Having a peek now. Looks like I.... did not fix this for 6.1.0 🤦🏻