log4j and other vulnerabilities in Autosys and Workload Control Center
search cancel

log4j and other vulnerabilities in Autosys and Workload Control Center

book

Article ID: 233782

calendar_today

Updated On:

Products

Autosys Workload Automation CA Workload Automation AE - Scheduler (AutoSys)

Issue/Introduction

Our security team has been running security scans, using Tenable, frequently since the log4j vulnerability was reported.

The scan has reported this file (lib/log4j-1.2.17.jar) in the Autosys application for the CVE's below. Some of this are high score vulnerabilities and the security team has asked us to quickly patch/mitigate or risk shutting Autosys down.

CVE-2019-17571

CVE-2020-9488

CVE-2022-23302

CVE-2022-23305

CVE-2022-23307

 

Environment

This is for following products/version:

Autosys 11.3.6, r12.0 and r12.0 SP1
WCC 11.4 SPn , r12.0 and r12.0 SP1

Resolution

CVE-2022-23302 - https://access.redhat.com/security/cve/CVE-2022-23302

JMSSink in Log4j 1.x is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if JMSSink is deployed and has been configured to perform JNDI requests.

JMSSink is not a default configuration which is enabled with Log4j. Also, Autosys and WCC do not use this JMSSink capability.

Mitigation

  • Restrict access for the OS user on the platform running the application to prevent modifying the Log4j configuration by the attacker.
  • Remove the JMSSink class from the server's jar files. For example:
    • zip -q -d log4j-*.jar org/apache/log4j/net/JMSSink.class

CVE-2022-23305 - https://access.redhat.com/security/cve/CVE-2022-23305

JDBCAppender in Log4j 1.x is vulnerable to SQL injection with untrusted data. This allows a remote attacker to run SQL statements in the database if the deployed application is configured to use JDBCAppender with certain interpolation tokens.

This JDBCAppender is not a default configuration which is enabled with Log4j. Also, Autosys and WCC do not use this JDBCAppender capability.

Mitigation

  • Restrict access for the OS user on the platform running the application to prevent modifying the Log4j configuration by the attacker.
  • Remove the JDBCAppender class from the server's jar files. For example:
    • zip -q -d log4j-*.jar org/apache/log4j/jdbc/JDBCAppender.class

CVE-2022-23307 - https://access.redhat.com/security/cve/cve-2022-23307

This can occur is when using the Chainsaw to view logs, especially if there is a log view available within the product itself.

There is no capability within the WCC to view the logs. Hence, we do not use the Chainsaw within Autosys nor WCC in any way.

Mitigation:

  • Remove the Chainsaw classes from the log4j jar files.
    • zip -q -d log4j-*.jar org/apache/log4j/chainsaw/*

CVE-2020-9488

Improper validation of certificate with host mismatch in Apache Log4j SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log messages sent through that appender.

Low impact with 3.7 score.

This SMTPAppender configuration is not enabled by default with Log4j. Also, Autosys and WCC does not use this capability in any way.

Mitigation:

  • Restrict access for the OS user on the platform running the application to prevent modifying the Log4j configuration by the attacker.
  • Remove the SMTPAppender classes from the log4j jar files.
    • zip -q -d log4j.jar org/apache/log4j/net/SMTPAppender.class

CVE-2019-17571

Log4j upstream strongly recommends against using the SerializedLayout with the SocketAppenders. The SocketAppender can be configured with the JsonLayout to accomplish the same thing in a way that does not expose the server to the serialization issues.

This SocketAppender configuration is not enabled by default with Log4j. The Log4j SocketServer should not be running. Also, Autosys and WCC does not use this capability in any way.

Mitigation:

  • Restrict access for the OS user on the platform running the application to prevent modifying the Log4j configuration by the attacker.
  • Remove the SocketServer classes from the log4j jar files.
    • zip -q -d log4j.jar org/apache/log4j/net/SocketServer.class
    • zip -q -d log4j.jar org/apache/log4j/net/SocketAppender.class