About the Log4Shell hazard
Learn how to get your storage system or server safe again.
First: Is any of the Open Source solutions offered by Starline affected by this vulnerability?
We have inspected all our Open Source-based solutions and integrations for traces of the Log4Shell vulnerability. None of the following solutions, in their delivered form, is affected:
Ambedded Ceph Storage
PetaSAN Ceph Storage
TrueNAS/FreeNAS and TrueNAS-Archiware/TrueNAS-Nextcloud integrations
Ubuntu-based Nextcloud systems
We will continue to scan our Open Source-based offerings for this vulnerability.
We are in contact with our suppliers to verify if any of their products could be affected. Here is what we know so far:
Microsemi/Adaptec’s storage manager maxView uses the Java library. The developers recommend using ARCCONF CLI instead, while the engineering team is working on a maxView patch version to fix the Log4j vulnerability in maxView.
Update 03/01/2022:
If you are currently using maxView, there may be a vulnerability in the program due to Apache Log4j Remote Code Execution (CVE-2021-44228).
Since maxView uses the Log4j 2.14.0 framework to log Tomcat web server logs, it falls under the list of affected products. Although maxView does not use or make available any JNDI functions, the lookup function that comes with maxView by default is not disabled in Log4j. Microchip Adaptec is working expeditiously to resolve this issue within maxView. Please follow ASK article 17523 for updates and final solutions.
Please click “Notify” in the article below to receive updates. (The option is only available if you are logged in there with your Microchip Adaptec account).
Firmware and software do not use Apache.
LSA is not affected.
MSM is using log4j in Version 1.2.15. Broadcom has identified MSM versions 17.05.04.00 through 17.06.02.01 as affected by the library. A team of developers is working to upgrade to the latest log4j version for the MSM software. Earlier versions of MSM should not be used.
Broadcom has released the following information about it.
PowerPanel Business software and PDNU2 utility use Log4j v.1.2.17. PowerPanel Business does not use JMSAppender in Log4J 1.2.17. Therefore, it is not affected by the current vulnerabilities.
SANsymphony
SANsymphony is unaffected by this issue. If you have affected components on the same server (e.g. if third party software has installed them) then they can be updated as per any 3rd party software.
Swarm
The Apache Log4j2 library is used by some versions of the Gateway and Elasticsearch features of Swarm. FileFly does not make use of Log4j2 and is therefore not affected. For more information on how this issue affects Swarm, and workarounds for affected releases, see: DataCore Swarm log4j Remediation (CVE-2021-44228)
vFilO
The Apache Log4j2 library is used for logging by some vFilO components, and all releases of vFilO available from the DataCore download portal are affected by this issue.
Using this vulnerability, an attacker with direct network access (e.g., without any firewall between the attacker and the vFilO system) could induce vFilO to open a JNDI connection to a remote LDAP server, retrieve and execute arbitrary code. This could lead to unintended information disclosure, the addition or modification of data, or Denial of Service (DoS).
A fix is available in build 4.6.4-116. You can obtain the update package by opening an incident with DataCore Support. When raising the case please detail the release you are presently running.
Infortrend has closed the Log4j gap with new firmware. They were able to patch the Log4j gap within the affected GS series with firmware version 1.52E44.
Infotrend’s SANWatch and Central EonOne are not affected.
NAKIVO Backup & Replication is using the Apache Log4j library, which is part of Apache Logging Services. NAKIVO have issued a Security Alert which includes detailed steps on how to mitigate this issue. Please see below for more information.
For Linux: Follow this link
For Windows: Remove the JndiLookup.class file from the log4j-core-2.2.jar jar file by following the steps below:
1. Make sure you have the 7z tool installed.
2. Go to the libs folder which is located inside NAKIVO Backup & Replication installation folder.
3. Use 7z to open the log4j-core-2.2.jar file.
4. Remove the JndiLookup.class file located in the org/apache/logging/log4j/core/lookup folder of the jar file.
5. Restart NAKIVO Backup & Replication.
Models with the proprietary OS7 operating system are not affected by the problem. Our technical engineer have examined the the NASDeluxe NDL-2800SR and NDL-2880R systems and found no traces of the Log4j library or the Java binariy itself. In addition to our findings, we have received a confirmation from the manufacturer that the latest firmware (version 2.06.03) does not contain the Java binaries. Please see below for more information on how to check your NDL-2xxx systems. We will update this section should we receive more relevant information.
Here are the steps, should you want to verify on your own
NEC developers (TopRAID) told us that the problem (CVE-2021-44228) has been investigated and only the “Storage Analyzer for VMware vRealize Operations” could be affected by this problem. (So the VMware software and not the NEC product itself.) They also confirmed that there were no other issues related to CVE-2021-44228 and NEC storage products.
Netgear told us that their switches were not affected by the gap.
The Power Manager software is affected. Supermicro is working on an upgrade to Log4j version 2.15.0 and will promptly release a new SPM.
