portdirectory.blogg.se - Logger pro 3.12 beta

#Logger pro 3.12 beta upgrade
#Logger pro 3.12 beta software

After review, there is no problems for Mirth Connect.

Security updates are defined and provided by our security champion, Nick Rupley.

Here is where we are today for Mirth Connect: If you missed the webinar earlier this month, we reviewed and documented why Mirth Connect is NOT vulnerable with. Additionally, these rarely used vulnerable features are not compatible with log4j 2.x, so either way it would be up to the user, not mirth, to rectify the problem.īeta Was this translation helpful? Give feedback. In mirth's case, none of the log4j 1.x vulnerabilities apply unless the user has added in customizations which do not ship with mirth to activate these rarely used vulnerable features.

#Logger pro 3.12 beta software

When you are doing a risk analysis you need to determine not only if there are vulnerabilities reported for a particular piece of software you are using, but also whether or not you are using the software in a way that the vulnerability applies. The version of log4j that mirth is currently using has so far been shown to be more secure than versions that were released even after this discussion post originated. Your premise is wrong that you aren't getting a secure product.

#Logger pro 3.12 beta upgrade

If you are including log4j 2.x as a custom library and are using an older version of Java and can't easily upgrade, then follow the mitigation instructions and set the log4j2.formatMsgNoLookups system property to true, as well as the .ustURLCodebase and .ustURLCodebase system properties to false.Īs a side note we also have an item on our roadmap to upgrade log4j from 1.x to 2.x! It was just dumb luck I guess that we had not gotten around to doing that yet.īeta Was this translation helpful? Give FYI, (the guy with a Maintainer tag) is the only NextGen employee that has responded to this post. And even if you are, you still won't be vulnerable as long as you're using one of these Java versions or newer:

So as far as I can tell, MC is not affected by this CVE, unless you are explicitly including log4j 2.x as a custom library. In fact, that JndiLookup class isn't even present at all in the log4j 1.x JAR. I did that testing in older versions of Java like 8u60 as well. I tested logging out the exploit string described in the vulnerability, with a network capture going at the same time, and confirmed that the JNDI connection is not being made. Mirth Connect still uses log4j 1.2.16, and doesn't include log4j 2.x.