narupley
commented
2 years ago I don't think it was our intent to dismiss that, only that it belonged as issues here on the connect repository, instead of the connect-docker repository. And also probably that a single issue with all the CVEs listed needs to be split out into various libraries so that each issue can be separately tracked and triaged. We have our own internal third-party library vulnerability scans, and all of those libraries listed there we also have tickets internally to address. Some (but not all of) those internal tickets have corresponding issues here on GitHub though.
For the DoS vulnerability, is that one of the Jetty CVEs? We're actually in the process of updating Jetty right now with our latest release. And then we have other libraries with high/critical vulnerabilities slated right after that, including XStream, BouncyCastle, Apache Commons Fileupload. The log4j 2.x upgrade is there too, but not as high priority as those libraries.
Hope that helps, and sorry for the miscommunication there, we didn't mean to make it sound like we weren't concerned about those, it was more of a logistical thing about having it on the right repository and broken out into separate issues (if they don't already exist). These CVEs in third-party libraries are always on our radar, and we make sure to track and triage those internally and take them seriously. As far as the disclosure e-mail, that's a good point, we should add that to the GitHub policy here. We're having our IS team create an e-mail address specifically for this, and once that's done we'll update that and let you know!
MichaelLeeHobbs
yudong
Describe the security issue A clear and concise description of what the security issue is. Ex. Security scan reports "specific library" is vulnerability to these CVEs.
I have a working partial DOS attack. I can't say much more than that as it's very easy to exploit with publicly available examples that work on connect. I found this attack by working through the list of CVE's post here https://github.com/nextgenhealthcare/connect-docker/issues/16#event-6012259444 The attack is easy to execute on any publicly exposed mirth server and consumes 80-90% of the servers compute resource. The relevant CVE is also listed on #4990.
Vulnerability Location Is this a vulnerability in a 3rd party library or the Connect codebase itself? It's a third part library that has a fix.
Environment (please complete the following information if it is applicable to the issue)
Suggested remediation Recommendations on how to fix vulnerability. Ex. Update library to version "x.x.x". - Update your libraries, this will fix 98% of the open CVEs if not all of them.
Additional context Add any other context about the problem here.
Please provide secure disclosure instructions ie https://github.com/nextgenhealthcare/connect/security/policy. If you had this in place I would not have had to open this issue.
I just want to say I find the response to https://github.com/nextgenhealthcare/connect-docker/issues/16#event-6012259444 shameful and it reeks of laziness. I am by no means a security research or hacker and it only took me 30 minutes and 2 attempts to find and exploit a open CVE security vulnerability.