Log4Shell
CVE-2021-44228 describes a remote code execution vulnerability in Log4J 2.
We can confirm that our Maverick Java SSH APIs do not depend on Log4J 2, and we do not distribute the affected versions with our APIs as a third-party dependency.
However, using these versions with our library through the SLF4J facade we use to log is still possible.
We understand that the Log4J 2 vulnerabilities are possible by logging user input. Whilst we do not log the content of user sessions without explicit configuration, customers should deem the exchange of information within the SSH protocol as user input. For example, we might log an incompatible key exchange algorithm supplied by the remote party, its identification string, the user’s name, or an SFTP path. All these could potentially contain exploits by a rogue SSH implementation.
Therefore, using the affected Log4J 2 versions with our Javas SSH APIs could leave your products vulnerable to these exploits. We recommend that customers using Log4J 2 take all the mitigating steps published by the Apache Foundation to remove the risk.
Issues with Log4J 1.2.17
The broad exposure of this recent vulnerability has also prompted customers to raise concerns regarding issues with the Log4J version in our currently distributed version, 1.2.17.
Reports have shown that this version may also be vulnerable to CVE-2021-44228 and remote code execution when using the JMS Appender class.
CVE 2020-9488 relates to SMTP appender and man-in-the-middle attacks.
Similarly, CVE 2019-17571 relates to ServerSocket implementation, which is vulnerable to deserialization attacks.
Our Java SSH APIs do not enforce the use of any of the described features. If configured using examples provided by Jadaptive that use simple console or file appenders, your Log4J would not be vulnerable even when using an affected version unless you have configured Log4J to use the above appenders in your environment.
No Dependency
While we distribute versions of Log4J as optional dependencies, our libraries do not depend on any Log4J version, and their presence is not required to compile or use our products.
Logging behaviour is a choice you make in your build and production environments, so we encourage all vendors to thoroughly analyze their logging usage to ensure they are not vulnerable. Customers should not rely on any statement we have made regarding the suitability of third-party products.
Removing Log4J
From version 1.7.33 onwards, our releases include a simple internal implementation of an SLF4J provider that logs to the console or file. This provider could be used as a suitable replacement and requires that you drop the maverick-slf4j.jar file in your classpath and remove the slf4j-log4j12.jar. Logging can be controlled by code or by a simple properties file. Further documentation is available at the URL below.
https://jadaptive.com/app/manpage/en/article/1564873
We will remove all versions of Log4J from our products from the next release, 1.7.41, scheduled for release in early January.
Maverick Synergy
Customers using our Maverick Synergy Java SSH API should not be vulnerable to the Log4J issues outlined above as the API uses the Maverick logging provider directly without SLF4J. However, we recommend you review your entire application usage and not rely on this as a statement that applies to your wider implementation.