United States
Log4j Vulnerability Status
January 28, 2022Introduction
Some NEC products and solutions include a version of the logging component "Log4j" which is now known to have severe security vulnerabilities. The vulnerabilities may be mitigated by various actions. This article lists the known vulnerability status at time of writing and is intended to be useful to NEC partners and customers.
It is updated as new information becomes known to NEC.
Background
On December 10, 2021, NIST announced a critical security issue in Log4j, a widely-used software component for logging. The critical vulnerability is sometimes called "log4shell".
NIST announced other related vulnerabilities in the following weeks. For more information, see the Log4j - Apache Log4j Security Vulnerabilities page.
The critical vulnerability affects Java software that use Apache Log4j versions 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0.
Log4j version 2.16.0 fixes this critical issue by removing support for message lookup patterns and disabling JNDI functionality by default. Log4j version 2.17.1 fixes other medium-level vulnerabilities.
A high-level vulnerability in Log4j version 1.2, CVE-2021-4104, only affects software that use JMSAppender, which is not the default.
Product Matrix
| Product | Vulnerability Status | Note |
|---|---|---|
| SL1000 | Not Vulnerable | No Log4j |
| SL1100 | ||
| SL2100 | ||
| UNIVERGE SV8100 | ||
| UNIVERGE SV9100 | ||
| UNIVERGE Aspire X | ||
| UNIVERGE Aspire UX | ||
| UNIVERGE Aspire WX | Not Vulnerable | No Log4j |
| UNIVERGE SV8300 | Not Vulnerable | No Java |
| UNIVERGE SV9300 | ||
| UNIVERGE SV8500 | Not Vulnerable | No Java |
| UNIVERGE SV9500 | ||
| UNIVERGE 3C Unified Communication Manager (UCM) | Vulnerable | UCM v9.3 and earlier are not vulnerable. UCM v10.0 (up to P3) and v10.1 (unpatched) include a vulnerable version of Log4j. See the Mitigation Steps section below. |
| UNIVERGE UC Connector | Not Vulnerable | No Java |
| UNIVERGE Business ConneCT (BCT) | Not Vulnerable | |
| UC for Enterprise (UCE) Application Platform | Not Vulnerable | UCE OpenFire service has Log4j but not a vulnerable version. |
| UC for Enterprise (UCE) Attendant | Not Vulnerable | UCE Patient link, Attendant Statistics, and Guest Link services have Log4j but not a vulnerable version. |
| UC for Enterprise (UCE) Manager (MA4000) | Not Vulnerable | |
| Expense Management | Not Vulnerable | |
| UNIVERGE 3C UC Client | Not Vulnerable | |
| UNIVERGE 3C Mobile Client | Not Vulnerable | |
| UC for Enterprise (UCE) Desktop Client/Agent | Not Vulnerable | No Java |
| UC for Enterprise (UCE) Mobility | Not Vulnerable | No Log4j |
| TigerTMS | Not Vulnerable | |
| SLC (uMobility) | Not Vulnerable | |
| UNIVERGE Soft Client SP350 | Not Vulnerable | No Log4j |
| MyCalls | Not Vulnerable | |
| MobiCall | Not Vulnerable | See MobiCall / MobiBBox / MobiCCloud is not affected by Log4j - New Voice International |
| SIP@net server | Not Vulnerable |
Mitigation Steps for UNIVERGE 3C
UNIVERGE 3C system versions v10.0 (up to P3) and v10.1 (unpatched) include a vulnerable version of Log4j.
- For v9.3 and earlier, no action is required. The system is not vulnerable.
- For v10.0 (up to P3), apply Patch 4 ("P4") to mitigate the vulnerability.
- For v10.1 (unpatched), apply Patch 1 ("P1") to mitigate the vulnerability.
- 3C UC Client and 3C Mobile Clients do not include Log4j, and are unaffected.
For further information, see 3C Technical Bulletin TB146 ("UNIVERGE 3C System Level of Exposure to Log4j Vulnerability").
Mitigation Steps for ESMPro
Notes on vulnerability(CVE-2021-44228, CVE-2021-45046) in Apache Log4j Libraries of NEC ESMPRO Manager Ver.6.37-6.56
Mitigation Steps for NOE Virtual Network Dashboard
Step 1: Edit the jvm.options file
In the configuration file /etc/elasticsearch/jvm.options, add the following parameters.
-Dlog4j2.formatMsgNoLookups=true
Step 2: Restart the service
# systemctl restart kibana
# systemctl restart elasticsearch
Mitigation Steps for Masterscope NFA
Step 1: Disable lookup function of Log4j
To follow this step, "zip" command must be installed in your machine
1.1. Stop NFA service
# /etc/init.d/nec-nfa-service stop
1.2. Backup Log4j file to any diretory on your machine.
At default, NFA is installed on /opt/nec/nfa.
# cp -a <NFA install directory>/controller/lib/log4j-core-*.jar <backup directory>
1.3. Remove JndiLookup.class, which execute Lookup function, from Log4j file
# zip -q -d <NFA install directory>/controller/lib/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
1.4. Start NFA service
# /etc/init.d/nec-nfa-service start
Step 2: Confirm if Lookup function is disabled
To follow this step, "unzip" command must be installed in your machine
2.1. Copy Log4j file which you have disabled Lookup function to any working directory
# cp -a <NFA install directory>/controller/lib/log4j-core-*.jar <working directory>
2.2. Change to the working directory
# cd <working directory>
2.3. Unzip Log4j file on the working directory
# unzip log4j-core-*.jar
2.4. Confirm JndiLookup.class is not included
# find . -name JndiLookup.class
If JndiLookup.class is included, following message will be displayed
./org/apache/logging/log4j/core/lookup/JndiLookup.class
Mitigation Steps for PFC - SC module
Add -Dlog4j2.formatMsgNoLookups = true to JAVA_OPTS in /opt/nec/sc/tomcat/bin/setenv.sh
Restart SC.