Log4j Vulnerability Update
On December 10, 2021, MIM Software became aware of Critical Vulnerability Exploit CVE-2021-44228.
MIM Software engineers continuously track global CVE databases. They investigated the matter as soon as the first vulnerability was published. Upon investigation, it was determined that no MIM Software products are affected by this CVE or any other Log4j CVEs reported by the National Institute of Standards and Technology.
What is Log4j?
Log4j is an open-source library that logs events such as error messages and other diagnostic operations in software applications.
For more information, click here.
Log4j Versions in Use by MIM Software Products
| MIM Software Product |
Log4j Version |
| MIM® |
1.2.17 |
| MIMcloud Assistant™ |
1.2.16 |
| MIMcloud Organizer™ |
1.2.16 |
| MIMcloud® |
1.2.8 |
| HQ Server |
1.2.16 |
Log4j 1.x CVEs
The table below displays the current CVEs for 1.x versions of Log4j. (Source: National Vulnerability Database)
CVE
Description
Is MIM Software Vulnerable to This CVE?
Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data, which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2.17.7
No – MIM Software code does not contain any references to the SocketServer class.
JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations, causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228.
No – MIM Software code does not contain any references to JMSAppender. In addition, exploiting this requires that, "the attacker has write access to the Log4j configuration," which would imply they have access to the system on which MIM is running. In this situation, the attacker has already compromised the system through an additional exploit.
Log4j 2.x CVEs
The table below displays the current CVEs for 2.x versions of Log4j. (Source: National Vulnerability Database)
CVE
Description
Is MIM Software Vulnerable to This CVE?
Improper validation of certificate with host mismatch in Apache Log4j SMTP appender. This could allow an SMTPS connection to be intercepted by an attack, which could leak any log messages sent through that appender.
No – MIM Software products are not using any versions of Log4j 2.x.
In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.
No – MIM Software products are not using any versions of Log4j 2.x.
Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
No – MIM Software products are not using any versions of Log4j 2.x.
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in an information leak and remote code execution in some environments and local code execution in all environments.
No – MIM Software products are not using any versions of Log4j 2.x.
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
No – MIM Software products are not using any versions of Log4j 2.x.
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted.
No – MIM Software products are not using any versions of Log4j 2.x.
Frequently Asked Questions
Why do MIM Software products use an earlier version of Log4j? Am I at risk because of this?
You are not at risk. MIM Software products are not vulnerable to any Log4j CVEs reported by the National Institute of Standards and Technology.
Many software programs utilize various open-source libraries and code that are necessary tools for the software to run properly. MIM Software, as the publisher of its software, is responsible for all libraries that are included in MIM Software products.
Any reference to a library such as Log4j is only upgraded within the MIM version. There is no need to access it directly from the internet or independently upgrade. Per MIM Software’s Quality Management System, all MIM versions are fully evaluated for vulnerabilities prior to commercial release.
Additionally, Log4j 1.x and Log4j 2.x versions are essentially different libraries created by different development teams. Software applications using Log4j 1.x versions are not necessarily automatically compatible with the Log4j 2.x API. MIM Software will consider compatibility and vulnerability for future use of any version of Log4j.
Is MIM Software planning to remove Log4j from its software?
Yes. All future MIM versions, starting with MIM 7.1.7, will have all versions of Log4j removed.
This is only a precautionary measure, as no vulnerabilities to current Log4j versions used by MIM Software products are known. MIM Software customers are not required to upgrade at this time.
How does this affect me? What does my IT department need to do?
All versions of MIM are safe from any known CVEs, and no action needs to be taken at this time. Once it is commercially available, you can choose to upgrade to MIM 7.1.7 if you’d like to remove Log4j from your MIM application. This is not a requirement, however, as MIM Software products are not at risk for any known CVEs.
While MIM Software cannot predict whether its products will be vulnerable to a future CVE, if any vulnerabilities are discovered in a MIM Software product, you will be promptly notified via email.
If you would like to download a PDF with this information, please click the button below.
Download PDF
Additional Questions
If you have any additional questions, please fill out the form below.
