log4j and other vulnerabilities in Autosys and Workload Control Center
Article ID: 233782
Updated On:
Products
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
Feedback
