Powered byCRASHPLAN

Questions? Call +31-157-112-149
or Contact us online

Is my CrashPlan unsafe due to log4j vulnerabilities?

Version 2010: no

CrashPlan client software version 2010 does not include log4j.

Version 3.x: Probably not

CrashPlan version 3.x client software contains log4j version 1.2.16. Log4j v2 is not used by CrashPlan Pro (v2010) or CrashPlan PROe (v3). Log4j version 1.x does not contain a log4shell vulnerability, but it does contain a number of other vulnerabilities that require configuration changes in order to be exploited.

The vulnerable classes are not in use by the CrashPlan client and may– if desired – be removed permanently. How to do so is explained at the bottom of this page.

Vulnerabilities in log4j

These are the vulnerabilities found in Apache log4j 2.x and vulnerabilities found in log4j 1.2 software:

  1. CVE-2022-23307: Chainsaw component of Log4j 1.2.x contains a critical error. This is the same problem that was corrected in CVE-2020-9493.
    CrashPlan client v3 does not use the "ChainSaw" class. You can remove the Chainsaw classes from the class path:
    $ sudo zip -d log4j-1.2.16.jar "org/apache/log4j/chainsaw/*.class"
  2. CVE-2022-23305: JDBCAppender in Log4j 1.2.x is designed to accept an SQL statement as a configuration parameter where the values to be inserted are PatternLayout converters. The message converter, %m, will probably always be included. This allows attackers to manipulate the SQL by inserting crafted strings into input fields or application headers that are being logged, allowing unintended SQL queries to be executed. Note that this problem only occurs in Log4j 1.x when it is specifically configured to use the JDBCAppender, which is not the default.
    You can permanently remove the JDBCAppender class – which is not used by the CrashPlan v3 client – from the class path:
    $ sudo zip -d log4j-1.2.16.jar org/apache/log4j/jdbc/JDBCAppender.class
  3. CVE-2022-23302: JMSSink in all versions of Log4j 1.x is vulnerable to deserialisation of untrusted data if the attacker has write access to the Log4j configuration or if the configuration points to an LDAP service that the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration that causes JMSSink to execute JNDI requests that result in the remote execution of code in a manner similar to CVE-2021-4104. Note that this issue only affects Log4j 1.x when it is specifically configured to use JMSSink, which is not the default.
    You can permanently remove the JMSSink class – which is not used by the CrashPlan v3 client – from the class path:
    $ sudo zip -d log4j-1.2.16.jar org/apache/log4j/net/JMSSink.class
  4. CVE-2021-45105: Log4j 1.x is not affected by this vulnerability.
  5. CVE-2021-45046: Log4j 1.x is not affected by this vulnerability.
  6. CVE-2021-44832: Log4j 1.x is not affected by this vulnerability.
  7. CVE-2021-44228: Log4shell: Log4j 1.x has no Lookups, so the risk is lower. Applications that use Log4j 1.2 are only vulnerable to this attack if it is specifically configured to use JMSAppender, which is not the default. A separate CVE (CVE-2021-4104) has been submitted for this vulnerability.
  8. CVE-2021-4104: JMSAppender in Log4j 1.2 is vulnerable to deserialisation of untrusted data if the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations that allow JMSAppender to execute JNDI requests that result in remote code execution in a similar manner to CVE-2021-44228. Note that this issue only affects Log4j 1.2 when it is specifically configured to use JMSAppender, which is not the default.
    You can permanently remove the JMSAppender class – which is not used by the CrashPlan v3 client – from the class path:
    $ sudo zip -d log4j-1.2.16.jar org/apache/log4j/net/JMSAppender.class
  9. CVE-2020-9488: Log4j 1.x is not affected by this vulnerability.
  10. CVE-2019-17571: This affects Log4j versions up to 1.2 to 1.2.17. Log4j 1.2 contains a SocketServer class that is vulnerable to untrusted data deserialisation, which can be abused to remotely execute arbitrary code when combined with a deserialisation gadget when listening to untrusted network traffic for log data.
    You can permanently delete the SocketServer class – which is not used by the CrashPlan v3 client – from the class path:
    $ sudo zip -d log4j-1.2.16.jar org/apache/log4j/net/SocketServer.class
  11. CVE-2020-9488: This is a moderately serious problem with the SMTPAppender. Incorrect validation of certificate with host mismatch in Apache Log4j SMTP appender. This allows an SMTPS connection to be intercepted by a man-in-the-middle attack that can leak log messages sent via that appender.
    You can permanently remove the SMTPAppender class – which is not used by the CrashPlan v3 client – from the class path:
    $ sudo zip -d log4j-1.2.16.jar "org/apache/log4j/net/SMTPAppender*.class"
  12. CVE-2017-5645: Log4j 1.x is not affected by this vulnerability.

Remove potential vulnerabilities in CrashPlan 3.x client

Windows

  • Install 7-zip.
  • Open cmd as administrator.
  • cd "C:\Program Files\CrashPlan\lib"
  • for /R %f in (*log4j-1.2.16.jar) do "C:\Program Files\7-Zip\7z" d %f "org/apache/log4j/{chainsaw/*,jdbc/JDBCAppender,net/JMSSink,net/JMSAppender,net/SocketServer,net/SMTPAppender*}.class"

Mac OS X

  • Open the Terminal app.
  • cd /Applications/CrashPlan.app/Contents/Resources/Java/lib/
  • zip -d log4j-1.2.16.jar "org/apache/log4j/{chainsaw/*,jdbc/JDBCAppender,net/JMSSink,net/JMSAppender,net/SocketServer,net/SMTPAppender*}.class"

Linux

  • Install zip.
  • zip -d {/usr/local/crashplan/lib/log4j-1.2.16.jar "org/apache/log4j/{chainsaw/*,jdbc/JDBCAppender,net/JMSSink,net/JMSAppender,net/SocketServer,net/SMTPAppender*}.class"

Keep any backup copy of the file log4j-1.2.16.jar outside the /lib/ directory, otherwise the deleted classes will still be loaded from the backup.

Ist mein CrashPlan aufgrund von log4j-Sicherheitslücken unsicher? Is mijn CrashPlan onveilig door log4j kwetsbaarheden?