[SECURITY] Multiple High and Critial CVEs found in MirthConnect 3.12.0 with Anchore grype scan

[yudong]

Describe the security issue
Multiple CVEs reported as High and Critical rating after scanning with Anchore grype tool.

Vulnerability Location
CVEs are 3rd party libraries such as log4j 1.2.16, xstream 1.4.12 etc.

Environment (please complete the following information if it is applicable to the issue)

• OS: RedHat 8 ubi 8.5
• Java Distribution/Version OpenJDK 17
• Connect Version 3.12.0

Suggested remediation
CVE scanning and reporting are important tools that helps hospital to improve cybersecurity posture. As an HL7 message engine, Mirth Connect plays an important role in hospital IT infrastructure.

I am wondering what CVE scan tool does Mirth Connect Dev team use before each release. Are there any plan in place and timeline to address reported CVEs. What can I do to help?

So that we can assure hospital customers that Mirth Connect is solid in Cybersecurity.

Additional context
Here is the scan result from Anchore grype
Component version used, version fixed cve severity
commons-beanutils 1.9.3 1.9.4 GHSA-6phf-73q6-gh87 High
commons-beanutils 1.9.3 CVE-2019-10086 High
commons-compress 1.17 1.19 GHSA-53x6-4x5p-rrvv High
commons-compress 1.17 1.21 GHSA-7hfm-57qf-j43q High
commons-compress 1.17 1.21 GHSA-crv7-7245-f45f High
commons-compress 1.17 1.21 GHSA-mc84-pj99-q6hh High
commons-compress 1.17 1.21 GHSA-xqfj-vm6h-2x34 High
commons-compress 1.17 CVE-2019-12402 High
commons-compress 1.17 CVE-2021-35515 High
commons-compress 1.17 CVE-2021-35516 High
commons-compress 1.17 CVE-2021-35517 High
commons-compress 1.17 CVE-2021-36090 High
commons-email 1.3.1 CVE-2017-9801 High
commons-email 1.3.1 CVE-2018-1294 High
commons-fileupload 1.2.1 1.3.2 GHSA-fvm3-cfvj-gxqq High
commons-fileupload 1.2.1 1.3.1 GHSA-xx68-jfcg-xmmf High
commons-fileupload 1.2.1 1.3.3 GHSA-7x9j-7223-rg5m Critical
commons-fileupload 1.2.1 CVE-2014-0050 High
commons-fileupload 1.2.1 CVE-2016-1000031 Critical
commons-fileupload 1.2.1 CVE-2016-3092 High
derby 10.10.2.0 CVE-2015-1832 Critical
geronimo-j2ee-management_1.1_spec 1.0.1 CVE-2011-5034 High
geronimo-jms_1.1_spec 1.1.1 CVE-2011-5034 High
jackson-dataformat-cbor 2.11.3 2.11.4 GHSA-xmc8-26q4-qjhx High
jdom 1.1.1 CVE-2021-33813 High
jetty-annotations 9.4.21.v20190926 CVE-2020-27216 High
jetty-annotations 9.4.21.v20190926 CVE-2021-28165 High
jetty-continuation 9.4.21.v20190926 CVE-2020-27216 High
jetty-continuation 9.4.21.v20190926 CVE-2021-28165 High
jetty-http 9.4.21.v20190926 CVE-2020-27216 High
jetty-http 9.4.21.v20190926 CVE-2021-28165 High
jetty-io 9.4.21.v20190926 9.4.39 GHSA-26vr-8j45-3r4w High
jetty-io 9.4.21.v20190926 CVE-2020-27216 High
jetty-io 9.4.21.v20190926 CVE-2021-28165 High
jetty-plus 9.4.21.v20190926 CVE-2020-27216 High
jetty-plus 9.4.21.v20190926 CVE-2021-28165 High
jetty-rewrite 9.4.21.v20190926 CVE-2020-27216 High
jetty-rewrite 9.4.21.v20190926 CVE-2021-28165 High
jetty-schemas 3.1.M0 CVE-2009-5045 High
jetty-schemas 3.1.M0 CVE-2017-7656 High
jetty-schemas 3.1.M0 CVE-2017-7657 Critical
jetty-schemas 3.1.M0 CVE-2017-7658 Critical
jetty-schemas 3.1.M0 CVE-2017-9735 High
jetty-schemas 3.1.M0 CVE-2020-27216 High
jetty-security 9.4.21.v20190926 CVE-2020-27216 High
jetty-security 9.4.21.v20190926 CVE-2021-28165 High
jetty-server 9.4.21.v20190926 CVE-2020-27216 High
jetty-server 9.4.21.v20190926 CVE-2021-28165 High
jetty-servlet 9.4.21.v20190926 CVE-2020-27216 High
jetty-servlet 9.4.21.v20190926 CVE-2021-28165 High
jetty-util 9.4.21.v20190926 CVE-2020-27216 High
jetty-util 9.4.21.v20190926 CVE-2021-28165 High
jetty-webapp 9.4.21.v20190926 9.4.33 GHSA-g3wg-6mcf-8jj6 High
jetty-webapp 9.4.21.v20190926 CVE-2020-27216 High
jetty-webapp 9.4.21.v20190926 CVE-2021-28165 High
jetty-xml 9.4.21.v20190926 CVE-2020-27216 High
jetty-xml 9.4.21.v20190926 CVE-2021-28165 High
log4j 1.2.16 GHSA-2qrg-x229-3v8q Critical
log4j 1.2.16 GHSA-fp5r-v3w9-4333 High
log4j 1.2.16 CVE-2019-17571 Critical
log4j 1.2.16 CVE-2022-23302 High
log4j 1.2.16 CVE-2022-23305 Critical
log4j 1.2.16 CVE-2022-23307 Critical
mybatis 3.1.1 3.5.6 GHSA-qq48-m4jx-xqh8 High
mybatis 3.1.1 CVE-2020-26945 High
netty-reactive-streams 2.0.5 CVE-2015-2156 High
netty-reactive-streams 2.0.5 CVE-2019-16869 High
netty-reactive-streams 2.0.5 CVE-2019-20444 Critical
netty-reactive-streams 2.0.5 CVE-2019-20445 Critical
netty-reactive-streams 2.0.5 CVE-2021-37136 High
netty-reactive-streams 2.0.5 CVE-2021-37137 High
netty-reactive-streams-http 2.0.5 CVE-2015-2156 High
netty-reactive-streams-http 2.0.5 CVE-2019-16869 High
netty-reactive-streams-http 2.0.5 CVE-2019-20444 Critical
netty-reactive-streams-http 2.0.5 CVE-2019-20445 Critical
netty-reactive-streams-http 2.0.5 CVE-2021-37136 High
netty-reactive-streams-http 2.0.5 CVE-2021-37137 High
org.eclipse.jetty.apache-jsp 9.4.21.v20190926 CVE-2020-27216 High
org.eclipse.jetty.apache-jsp 9.4.21.v20190926 CVE-2021-28165 High
xstream 1.4.12 1.4.14-jdk7 GHSA-mw36-7c6c-q4q2 High
xstream 1.4.12 1.4.17 GHSA-7chv-rrw6-w6fc High
xstream 1.4.12 1.4.18 GHSA-6w62-hx7r-mw68 High
xstream 1.4.12 1.4.18 GHSA-2q8x-2p7f-574v High
xstream 1.4.12 1.4.18 GHSA-hph2-m3g5-xxv4 High
xstream 1.4.12 1.4.18 GHSA-3ccq-5vw3-2p6x High
xstream 1.4.12 1.4.18 GHSA-qrx8-8545-4wg2 High
xstream 1.4.12 1.4.18 GHSA-h7v4-7xg3-hxcc High
xstream 1.4.12 1.4.18 GHSA-p8pq-r894-fm8f High
xstream 1.4.12 1.4.18 GHSA-8jrj-525p-826v High
xstream 1.4.12 1.4.18 GHSA-j9h8-phrw-h4fh High
xstream 1.4.12 1.4.18 GHSA-g5w6-mrj7-75h2 High
xstream 1.4.12 1.4.18 GHSA-64xx-cq4q-mf44 High
xstream 1.4.12 1.4.18 GHSA-cxfm-5m4g-x7xp High
xstream 1.4.12 1.4.18 GHSA-xw4p-crpj-vjx2 High
xstream 1.4.12 1.4.19 GHSA-rmr5-cpv2-vgjf High
xstream 1.4.12 1.4.15 GHSA-4cch-wxpw-8p28 High
xstream 1.4.12 1.4.16 GHSA-2p3x-qw9c-25hh High

[pacmano1]

Didn't you post this over at #4811?

I mean your list or most of it, nice of you to offer to help of course. Perhaps this story might be "Please define current security vulnerablity assessment and remediation for Mirth Connect open source".

Also a list of vulnerabilities in a given library doesn't mean the tool (mirth) is subject to that vulnerability. What would be very helpful in your post to for each vulnatability listed take the time to explore if mirth is affected, that would really help a lot of people. IMHO, Vulnetabilites need to be taken in the context of accessbility and actual exploitability, and that list doesn't share that either.

Sure I agree libraries should be updated of course, but posting long lists isn't all the helpful in the context of helping other understand of a particular vulnerabiltiy might affect them.

[yudong]

Yes. I did posted this over at 4811 and read your comment. Unfortunately, I don't think those comments move the conversation or Mirth Connect project forward.

I prefer to provide specifics, reproducible and actionable report to maintainers . It's up to them to draw conclusion and decide whether internal process improvement is needed or not. You can open a new issue with the title you suggested if you think it helps to get the right attention from the right people.

SBOM is gaining momentum because its simplicity and transparency - list of packages, EOL and CVEs. It helps IT teams to quickly understand a piece of software or their entire software inventory cybersecurity risks. It's the first line of defense for IT teams, hospitals included. At the same time, most IT teams will not have resource to explore whether Mirth is affected by each vulnerability uncovered by a CVE scanner.

Mirth Connect project will be much better off to provide a SBOM and a cleaner SBOM, by using up-to-date package with as fewer CVEs as possible.

If listed packages are not used by Mirth, why not just remove them from install packages - tar/zip files? Don't let these false positives negatively fest.

If listed packages are used by Mirth and fixed packages are available, why not plan to upgrade when resource is available? It's a tradeoff among removing a few High/Critical CVEs vs bug fixes vs adding a few new features. Why not prioritize addressing High/Critical CVEs for a release or tow?

Sorry. I am not a Java programmer to be more helpful. Even if I were, it would be appropriate for the core Mirth developers/maintainers to assess the risk and plan for mitigation in future releases.

For the moment, I can help with running CVEs scan's on released Mirth Connect versions.

[pacmano1]

I agree understanding that the process and timing for addressing CVEs (or for that matter features and PRs) would be valuable. You mentioned a few things that are probably business questions (e.g. prioritization of feature requests, CVEs, other PRs and so on) given a single entity "owns" (?) the software but people are free to do what they want and build their own updated projects. Will be interesting to see NG's response.

[pladesma]

We've updated most, but not all, of the listed libraries in 4.5.0. From your list, here are the ones we've updated:

• commons-beanutils
• commons-compress
• commons-fileupload
• jackson-dataformat-cbor
• jdom
• jetty-annotations
• jetty-continuation
• jetty-http
• jetty-io
• jetty-plus
• jetty-rewrite
• jetty-schemas
• jetty-security
• jetty-server
• jetty-servlet
• jetty-util
• jetty-webapp
• jetty-xml
• netty-reactive-streams
• xstream

Additionally, log4j was updated in a previous release.

Once 4.5.0 is released, refer to the Release Notes for more details.