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

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

Article: 100052105
Last Published: 2021-12-30
Ratings: 1 0
Product(s): Access, Appliances

IMPORTANT NOTES

Vulnerability scanners may still report the Log4j vulnerabilities even after applying the provided hot fix or 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 or the manual mitigation steps will 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

Product/Component Version Mitigation Steps

Access Appliance 3340 

7.3.2.x

Veritas strongly recommends customers upgrade to Access Appliance 7.4.3.200 or later release in order to be able to apply the Hot Fix or perform the mitigation steps provided below. 

 

Access Appliance 3340 

7.4.2.x Veritas strongly recommends customers upgrade to Access Appliance 7.4.3.200 or later release in order to be able to apply the Hot Fix or perform the mitigation steps provided below. 

Access Appliance 3340 

7.4.3.x

Download the Hot Fix provided here, or manually apply the mitigation steps listed below.                                                
The mitigation steps can be applied to any 7.4.3.x patch level. If a subsequent 7.4.3 patch is applied, then the mitigation steps will require to be reapplied.                                                                                                                              

Access 7.4.x 

BYOS (Bring your own server, non-appliance version)

There are no known issue with Access BYOS as the Apache Log4j package/files are not part of this software release. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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.  Regarding the recommendation to upgrade to 7.4.3.200 or later, Veritas is recommending the latest release to ensure our customers have the cumulative fixes that have been included in the latest release. 

If upgrading to Access 7.4.3.200 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.200 release notes here, and please engage Veritas Support regarding considerations for upgrading to 7.4.3.x, with reference to internal KB article 100051697.

 

Mitigation for Access Appliance 7.4.3.x with Hot Fix

Veritas has provided a Hot Fix that removes the vulnerable JNDI Lookup class.
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-ET4059261-7.4.3.0-1.x86_64.rpm

6. Install the Hot Fix
accessnode-01.Software> Install VRTSaccess-app-EEB-ET4059261-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-ET4059261-7.4.3.0-1.x86_64.rpm successfully.

7. (Optional) Use the steps listed in the manual mitigation steps below to validate that the JndiLookup.class is not present.

 

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

 

4. Start Access Infra Services with new log4j parameter setting

# 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.

Was this content helpful?