Impact of Apache Log4j Vulnerabilities On Access Appliances 3340 and Access BYOS

IMPORTANT NOTES

Vulnerability scanners may still report the Log4j vulnerabilities even after applying the provided mitigation steps. This is expected as most scanners are not designed to account for the mitigations.

VULNERABILITIES

CVE-2021-44228

Apache Log4j2 JNDI features do not protect against attacker-controlled LDAP and other JNDI related endpoints. Fixed in Log4j 2.15.0. Apache recommends upgrading to Log4j 2.15.0 or applying recommended mitigations immediately.

CVE-2021-45046

Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations. Fixed in Log4j 2.16.0. Apache recommends upgrading to Log4j 2.16.0 or applying recommended mitigations immediately. It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.

CVE-2021-45105

Apache Log4j2 does not always protect from infinite recursion in lookup evaluation.  Fixed in Log 4j 2.17.0. Apache recommends upgrading to Log4j 2.17.0. Access Appliances 3340 and BYOS are not impacted by this vulnerability.

CVE-2021-4104

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration.  Fixed in Log 4j 2. Apache recommends upgrading to Log4j 2. Access Appliances 3340 and BYOS are not exploitable by this vulnerability.

CVE-2021-44832

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 where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code.  Fixed in Log 4j 2.17.1. Apache recommends upgrading to Log4j 2.17.1. Access Appliances 3340 and BYOS are not exploitable by this vulnerability.

Impact Summary

There are Access Appliance Component(s) that use the vulnerable Apache Log4j version. However, the component(s) do not have any interface(s) that are exposed outside of the Access Appliance through any public IPs. Hence there is no exposure from any external user.

While there is no exposure from external users, in order to mitigate the vulnerability as recommended by Apache, the hot fix will upgrade log4j to a newer version.

The manual mitigation steps will only remove the vulnerable java class from the relevant jar files. However, as the jar file still exists, security scans may continue to flag the vulnerable jar file even though the vulnerable class has been removed.

Affected Access Appliance and Access BYOS Versions

Regarding log4j specifically, there is no difference in mitigation steps for Access 7.4.3.000, Access 7.4.3.100, or Access 7.4.3.200. 

Veritas recommends upgrading to version 8.0 where the log4j version is upgraded to 2.17.1.

If upgrading to Access 7.4.3.300 from an earlier version than Access 7.4.2.400, you must upgrade to 7.4.2.400, 7.4.3.000 or 7.4.3.100 first.  Please see the Access 7.4.3.300 release notes here, and please engage Veritas Support regarding considerations for upgrading to 7.4.3.x, with reference to internal KB article 100051697.

Upgrading to Access 8.0 is supported from any version at either 7.4.2 or 7.4.3. Please see the Access 8.0 release notes here.

Upgrading Log4j Version for Access Appliance 7.4.2.400 with Hot Fix

The EEB for version 7.4.2.400 is not cluster aware and must be applied to each node individually. repeat the procedure on each node of the appliance.

1. Download the Hot Fix from here.

2. Copy the Hot Fix to a single node of the 3340 Appliance cluster

        2a. Open a CIFS or NFS share via the Access Appliance CLISH to move the Hot Fix to the cluster node:

accessnode-01.Main_Menu> Manage
accessnode-01.Manage> Software
accessnode-01.Software> Share Open

3. Copy the Hot Fix to the CIFS or NFS directory

4. Close the share.
accessnode-01.Software> Share Close

5. List the downloaded file:

accessnode-01.Software> List Downloaded

Patch_Name                                        Size  Release_Date      Access_Version    Appliance_Version
VRTSaccess-app-EEB-ET4065022-7.4.2.400-1.x86_64.rpm
                                                  149M  Tue Feb 15 2022                     7.4.2.400

6. Install the Hot Fix
accessnode-01.Software> Install VRTSaccess-app-EEB-ET4065022-7.4.2.400-1.x86_64.rpm
- [Info] Successfully installed the EEB VRTSaccess-app-EEB-ET4065022-7.4.2.400-1.x86_64.rpm.

During installation the following error may be seen. The error is harmless and can be ignored

- [Error] Failed to backup appliance#network##2.0.2.war.

7. (Optional) Use the steps listed in the manual mitigation steps below to validate that the JndiLookup.class is now taken from log4j version 2.17.1.

# for log4jcore in `find /opt -name \*log4j\*core\*.jar 2> /dev/null`;do echo "In the file:
> $log4jcore"; unzip -l "$log4jcore" | grep JndiLookup.class; done
In the file:
/opt/autosupport/transmission/lib/log4j-core-2.17.1.jar
     3158  12-27-2021 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file:
/opt/autosupport/alertmanager/lib/log4j-core-2.17.1.jar
     3158  12-27-2021 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file:
/opt/autosupport/analyzer/lib/log4j-core-2.17.1.jar
     3158  12-27-2021 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file:
/opt/autosupport/fileuploader/lib/log4j-core-2.17.1.jar
     3158  12-27-2021 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file:
/opt/apache-tomcat/vxos/webapps/ascws/WEB-INF/lib/log4j-core-2.17.1.jar
     3158  12-27-2021 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class

Upgrading Log4j version for Access Appliance 7.4.3.200 with Hot Fix

Veritas has provided a Hot Fix  4064045 that upgrades log4j to a newer version. The initial hotfix, 4059261 only removed the vulnerable JNDI Lookup class and did not upgrade log4j.

If the initial hotfix, 4059261,  is already applied, then remove it prior to installing the newer hotfix.

This Hot Fix will only need to be copied to a single node; the installation process will sync the file to the second node in the cluster and apply the fix to both nodes. There are no downtime of any production services or reboots needed to apply this update.  The AutoSupport services will be restarted with both the Hot Fix or manual steps; however these are "non-production" services that are used for internal reporting - no data services such as file access or LTR, etc, are impacted.

1. Download the Hot Fix from here

2. Copy the Hot Fix to a single node of the 3340 Appliance cluster

        2a. Open a CIFS or NFS share via the Access Appliance CLISH to move the Hot Fix to the cluster node:

accessnode-01.Main_Menu> Manage
accessnode-01.Manage> Software
accessnode-01.Software> Share Open
- [Info] Created a NFS share for sharing the patches.
- [Info] You can access the NFS share at accessnode-01:/inst/patch/appliance/available. To ensure appliance security, use the Share Close command to remove the share after downloading the required patches.
- [Info] Created a CIFS share for sharing the patches.
- [Info] You can access the CIFS share at \\accessnode-01\incoming_patches. To ensure appliance security, use the Share Close command to remove the share after downloading the required patches.

3. Copy the Hot Fix to the CIFS or NFS directory

4. Close the share.
accessnode-01.Software> Share Close

5. List the downloaded file:

accessnode-01.Software> List Downloaded

| Name      | VRTSaccess-app-EEB-ET4064045-7.4.3.0-1.x86_64.rpm

6.  Rollback the original EEB, 4059261, if it was installed

accessmode-01.Software> Rollback  VRTSaccess-app-EEB-ET4059261-7.4.3.0-1.x86_64

7. Install the Hot Fix
accessnode-01.Software> Install VRTSaccess-app-EEB-ET4064045-7.4.3.0-1.x86_64.rpm
- [Info] Install EEB process started, please wait a moment...
- [Info] accessnode-01 - Prechecking for install the EEB...
- [Info] accessnode-02 - Prechecking for install the EEB...
- [Info] accessnode-01 - Installing the EEB...
- [Info] accessnode-02 - Installing the EEB...
- [Info] V-409-777-7003: Installed EEB VRTSaccess-app-EEB-ET4064045-7.4.3.0-1.x86_64.rpm successfully.

8. (Optional) Use the steps listed in the manual mitigation steps below to validate that the JndiLookup.class is now taken from log4j version 2.17.1.

# for log4jcore in `find /opt -name \*log4j\*core\*.jar 2> /dev/null`;do echo "In the file:
$log4jcore"; unzip -l "$log4jcore" | grep JndiLookup.class; done
In the file: /opt/autosupport/fileuploader/lib/log4j-core-2.17.1.jar
     3158  12-27-2021 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file: /opt/autosupport/analyzer/lib/log4j-core-2.17.1.jar
     3158  12-27-2021 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file: /opt/autosupport/alertmanager/lib/log4j-core-2.17.1.jar
     3158  12-27-2021 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file: /opt/autosupport/transmission/lib/log4j-core-2.17.1.jar
     3158  12-27-2021 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file: /opt/apache-tomcat/vxos/webapps/ascws/WEB-INF/lib/log4j-core-2.17.1.jar
     3158  12-27-2021 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class

Manual mitigation steps for Access Appliance 7.4.3.x, if unable to apply the Hot Fix

Note: Since Access Appliance 3340 is HA appliance please perform the following steps on BOTH NODES of the cluster.

1. Elevate to root:

Main_Menu> Support

Entering support utilities view...

Support> Maintenance

<!-- Maintenance Mode --!>

maintenance's password:

maintenance-!> /opt/Symantec/sdcssagent/IPS/sisipsoverride.sh;elevate

2. Stop Access Appliance Infra Services to add new log4j parameter setting

# as-collector stop

# as-analyzer stop

# as-alertmanager stop

# as-transmission stop

# systemctl stop tomcat-vxos

3. Update JndiLookup Class

The following command will identify which .jar files have the JndiLookup class present:

(command/output before removal)

# for log4jcore in `find /opt -name \*log4j\*core\*.jar 2> /dev/null`;do echo "In the file: $log4jcore"; unzip -l "$log4jcore" | grep JndiLookup.class; done
In the file: /opt/apache-tomcat/vxos/webapps/ascws/WEB-INF/lib/log4j-core-2.13.2.jar
2892 04-20-2020 21:37 org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file: /opt/autosupport/analyzer/lib/log4j-core-2.13.2.jar
2892 04-20-2020 21:37 org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file: /opt/autosupport/fileuploader/lib/log4j-core-2.13.2.jar
2892 04-20-2020 21:37 org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file: /opt/autosupport/transmission/lib/log4j-core-2.13.2.jar
2892 04-20-2020 21:37 org/apache/logging/log4j/core/lookup/JndiLookup.class
In the file: /opt/autosupport/alertmanager/lib/log4j-core-2.13.2.jar
2892 04-20-2020 21:37 org/apache/logging/log4j/core/lookup/JndiLookup.class

Remove the JndiLookup class:

# for log4jcore in `find /opt -name \*log4j\*core\*.jar 2> /dev/null`;do echo “$log4jcore”; zip -q -d $log4jcore org/apache/logging/log4j/core/lookup/JndiLookup.class;done
/opt/apache-tomcat/vxos/webapps/ascws/WEB-INF/lib/log4j-core-2.13.2.jar
/opt/autosupport/transmission/lib/log4j-core-2.13.2.jar
/opt/autosupport/alertmanager/lib/log4j-core-2.13.2.jar
/opt/autosupport/analyzer/lib/log4j-core-2.13.2.jar
/opt/autosupport/fileuploader/lib/log4j-core-2.13.2.jar

Confirm the .jar files no longer include the JndiLookup class:

(Command/output after removal)

# for log4jcore in `find /opt -name \*log4j\*core\*.jar 2> /dev/null`;do echo "In the file: $log4jcore"; unzip -l "$log4jcore" | grep JndiLookup.class; done
In the file: /opt/autosupport/fileuploader/lib/log4j-core-2.13.2.jar
In the file: /opt/autosupport/analyzer/lib/log4j-core-2.13.2.jar
In the file: /opt/autosupport/alertmanager/lib/log4j-core-2.13.2.jar
In the file: /opt/autosupport/transmission/lib/log4j-core-2.13.2.jar
In the file: /opt/apache-tomcat/vxos/webapps/ascws/WEB-INF/lib/log4j-core-2.13.2.jar

# systemctl start tomcat-vxos

# as-transmission start

# as-alertmanager start

# as-analyzer start

# as-collector start

Disclaimer

THE SECURITY ADVISORY IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. VERITAS TECHNOLOGIES LLC SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE.