Remote Code Execution Vulnerability (CVE-2023-43208) for older versions?

[pietew]

I'd like to bring up an important concern regarding the recent security patches and updates for Mirth Connect. As we know, Mirth Connect is a vital part of many healthcare organizations' infrastructure, serving as their centralized communication system.

Recently, we've seen the release of a patch (CVE-2023-43208) for Mirth Connect in version 4.4.1 to address a critical security vulnerability. We appreciate the swift action taken to enhance security in the latest version.

However, we understand that migrating from Mirth 3.x to Mirth 4.x can be a complex and time-consuming process for hospitals and healthcare institutions. Many of these organizations have been relying on older versions of Mirth Connect for their daily operations.

Our concern and question are: Is there any possibility that this important security patch could also be extended to older versions of Mirth Connect? This would greatly benefit healthcare facilities that are currently using older versions and may face challenges in immediately upgrading to version 4.x.

By providing a patch for older Mirth Connect versions, you would not only ensure the security of a significant number of healthcare systems but also allow these organizations more time and flexibility to plan and execute their upgrades.

We understand the complexities involved in software maintenance, but given the critical role Mirth Connect plays in healthcare communications, we believe that considering the security of older versions is of paramount importance.

We appreciate your attention to this matter and look forward to hearing your thoughts and any updates on this topic. Thank you for your commitment to improving the security and functionality of Mirth Connect.

[narupley]

If we did, maybe just 3.6.x and 3.12.x?

[pacmano1]

Not really pro or con to the original ask here but there are many ways to "delay" the impact of this CVE by contolling access to the server engine itself.

Also, If you have bad actors on your local network, you have a much larger problem than this CVE.

That could mean (other than obfuscatng stuff like changing ports):

1. On windows, requiring the admin tool to be run locally, i.e. block connections to port 8443 except from localhost and RDP to the server instead running the admin tool there. This (RDP access) does not require administrator permissions per se depending on machine poilicy.
2. On either windows or linux require a tunnel (e.g. ssh port forwarding), blocking the connections to port 8443 except from localhost. This would require an ssh server process of course. But even with the suggested patch, you still gotta touch the box anyway.
3. Some other secure traffic (e.g. IPSec, other internal VPN, probably more painful).

[pietew]

@narupley You raise a valid point regarding the potential scope of this endeavor. Indeed, addressing all 3.x versions, while commendable in terms of comprehensive security, can be an extensive and resource-intensive task. Given the challenges involved, focusing on version 3.12 may be a more practical approach that balances security needs with the realities of implementation.

@pacmano1 Thanks for mentioning these mitigations, was not aware that these options existed

[jonbartels]

@narupley I advocate AGAINST backporting the fix.

1. There are mitigations ranging from blocking ports to scanning traffic to zero-trust
2. Any backport incurs approximately the same testing overhead, risk, change management, downtime etc. as a full upgrade. Potentially more
3. Upgrading specific versions doesn't solve the issue. If a release is done for 3.6 and 3.12, theres going to be some folks still left out on 3.4, 3.8, 3.10, whatever
4. Users should be keeping up on routine upgrades anyway. NG releases at a steady cadence. (I am a hypocrite, that 3.2 instance just will.not.die :D )
5. I want NextGen engineers investing time in the next release. Spending time updating libraries, SBOMs, build scans, etc. to catch the next CVE early is more valuable than looking backwards

[kirbykn2]

Patch management. There should be no concern with upgrading (not migrating) to newer versions of Mirth, if you have a well defined process. Organizations that are serious about security, should be serious about keeping theirs systems up-to-date.

[pacmano1]

In the end it would be nice to see a current version - some X releases for back patching for CVEs though.

[pietew]

I've come across information that one of our hospitals have implemented and validated their own patch. This patch works with a specific version of the XStream library and is reportedly effective for multiple Mirth Connect versions.

Could this approach be a feasible solution for others? Specifically, is it possible to simply upgrade the XStream library to mitigate the vulnerability across various Mirth Connect versions?

Looking forward to your thoughts on this.

[jonbartels]

What would be helpful is that if that hospital would be willing to publish their patch under a permissive license (MIT, BSD, MPL) to help the community.

[tonygermano]

It is not possible to simply upgrade XStream and resolve the issue, because mirth changed from allowing practically anything to using a blacklist to using a whitelist in different mirth versions for classes that xstream is allowed to deserialize.

[pietew]

I think what they did is port the 4.4.1 commit to older versions, changing the donkey/src/main/java/com/mirth/connect/donkey/util/xstream/XStreamSerializer.java & server/src/com/mirth/connect/model/converters/ObjectXMLSerializer.java files and compile for each Mirth version.

Could this generate an updated jar file and serve as a patch?

[robertville50]

I've discovered that Amaron, a Belgian Mirth partner, has successfully implemented and validated NextGen's patch in a specific version of the XStream library. This adaptation reportedly makes the patch effective across multiple older versions of Mirth Connect.

It would greatly benefit the wider open-source community if Amaron would consider publishing their patch under a permissive license such as MIT, BSD, or MPL. This would enable others to utilize and potentially build upon their work, enhancing the security and functionality of Mirth Connect in various environments.

Link to Amaron's blog post: https://amaron.be/en/vulnerability-in-mirth-connect