NEC Product Security Advisory

Vulnerability in Apache Log4j Libraries Affecting NEC Enteprise Solutions Products

  • Publish Date: 2022-01-03
  • Revision: 1.4

Summary

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.

Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default.

Note that previous mitigations involving configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability.

Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath.

Example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Reference: CVE-2021-44228, CVE-2021-45046

Affected Products

3C UCM

  • UCM v9.3 and earlier are not vulnerable.
  • UCM v10.0 (up to P3) includes a vulnerable version of log4j.
  • See chapter “Mitigation Steps for 3C UCM” in this document

ESMPRO

HCI – SRxxx Lenovo

MasterScope

  • A patch is being prepared. Meantime, see the Mitigation Steps in chapter “Mitigation Steps for Masterscope NFA” in this document

NOE - UC-SDN

  • See chapter “Mitigation Steps for NOE - UC-SDN” in this document

NOE - Virtual Network Dashboard

  • See chapter “Mitigation Steps for NOE - Virtual Network Dashboard” in this document

Products Under Investigation

  • Express5800 General Purpose Server R120h-1M/2M
  • VPCC v6.x

Products Confirmed Not Vulnerable

  • 3C UC Client
  • 3C Mobile Client
  • AT-15/AT-35/AT-40/AT-45
  • Blueprint
  • Business Connect
  • DECT/ IP DECT
  • DT700/DT820/DT900 STD SIP
  • DT700/DT800/DT900/DT300/DT400/DT500/DT200
  • Express Cluster
  • Express5800 General Purpose Server  (all 100 series) Except for R120h-1M/2M
  • FDA
  • Fault Tolerant Servers (R320-g) and related control software
  • GT890
  • HCI – Scale Computing HC3
  • Hydrastor
  • InApps
  • KIOSK
  • LMS License Management (LMS/LMC)
  • Location Gateway
  • M-series Storage
  • MA4000 Expense Management
  • MA4000 System Management
  • MG-SIP, MCMG, VS32
  • MobiCall / MobiBox, see MobiCall / MobiBBox / MobiCCloud is not affected by log4j - New Voice International
  • MyCalls
  • MyCalls Call Recording
  • NEC Meeting Center (NMC)
  • OVOC
  • PCPro (SL2100/SV9100)
  • SIP@Net
  • SL1100/SL2100
  • SP310
  • SP350
  • ST500
  • SV8100/SV9100 CP10 & CP20
  • SV8300/SV9300
  • SV8500/SV9500
  • Tiger TMS
  • UC Connector
  • UC Suite
  • UG50
  • UIP
  • UM4730
  • UM8000
  • UM8700

    Our UM8700 Neverfail component does use Log4j, but it is an older version that is not affected by this vulnerability. Subject versions are v2beta – 2.14.  Following you will find the Neverfail knowledge base article on this topic. https://support.neverfail.com/portal/en/kb/articles/neverfail-official-statement-on-apache-log4j-vulnerability-cve-2021-44228

  • uMobility Enterprise Solution
  • UNIVERGE BLUE (Connect, Meet, Share, Engage)
  • UNIVERGE BX and MP Series
  • QX-Switches

Mitigation Steps for 3C UCM

UNIVERGE 3C system versions v10.0 (up to P3) includes 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.

3C UC Client and 3C Mobile Clients do not include Log4j, and are unaffected.

The New Maintenance Software release UNIVERGE 3C UCM v10.0.0.14_P4 is published on our Software Database

Mitigation Steps for NOE - UC-SDN

For NEO - UC-SDN, log4j is used by two functions:

  1. nwdoc (documentation)
  2. ems (ucsdn-SV9500).

If the application does not require those components we can temporary turn them off:

Step 1: Check Processes Using Log4j

Execute following command to check for processes that use log4j:
ps -ef | grep log4j

Example output of the command when processes are using log4j:

oe-elas+  1140     1 42 04:48 ?        00:00:09 /opt/nec/oe/nwdoc/elasticsearch/jdk/bin/java -Xshare:auto -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -XX:+ShowCodeDetailsInExceptionMessages -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dio.netty.allocator.numDirectArenas=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Djava.locale.providers=SPI,COMPAT -Xms1g -Xmx1g -XX:+UseG1GC -XX:G1ReservePercent=25 -XX:InitiatingHeapOccupancyPercent=30 -Djava.io.tmpdir=/tmp/elasticsearch-5434253224797553227 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=data -XX:ErrorFile=logs/hs_err_pid%p.log -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m -Des.transport.cname_in_publish_address=true -XX:MaxDirectMemorySize=536870912 -Des.path.home=/opt/nec/oe/nwdoc/elasticsearch -Des.path.conf=/opt/nec/oe/nwdoc/elasticsearch/config -Des.distribution.flavor=oss -Des.distribution.type=tar -Des.bundled_jdk=true -cp /opt/nec/oe/nwdoc/elasticsearch/lib/* org.elasticsearch.bootstrap.Elasticsearch -p /var/run/oe-elasticsearch/oe_elasticsearch.pid --quiet
root      1247     1  1 04:48 ?        00:00:00 /usr/java/jdk8/bin/java -cp ./log4j-1.2.16.jar:./emsMain.jar:./OaiLink.jar:./emsData.jar ems.EMSMain ./cfg/ems.cfg ./conditions/bootfile
root      3420  3284  0 04:49 pts/0    00:00:00 grep --color=auto log4j

Step 2: Disable log4j services

Turn off and disable services to prevent them from starting in the case that NOE is rebooted, by running the following commands:
systemctl stop oe-kibana
systemctl stop oe-elasticsearch
systemctl stop oailinkd
systemctl stop emsd
/opt/nec/ems/emsd stop

systemctl disable oe-kibana
systemctl disable oe-elasticsearch
systemctl disable oailinkd

 
#Note ems cannot do systemctl disable, we have to move the file out of the /etc/rc.d/init.d/ to a secure place. Later one we can put it back:

mv /etc/rc.d/init.d/ems /root

Step 3: Confirm log4j is Stopped

Repeat step 1 and verify the list of processes to confirm that log4j is stopped.
ps -ef | grep log4j

Expected output is just one item:

root      8295  3284  0 05:01 pts/0    00:00:00 grep --color=auto log4j

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 /controller/lib/log4j-core-*.jar

1.3. Remove JndiLookup.class, which execute Lookup function, from Log4j file
# zip -q -d /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 /controller/lib/log4j-core-*.jar

2.2. Change to the working directory
# cd

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

Other useful information sources:

https://logging.apache.org/log4j/2.x/security.html
https://www.necplatforms.co.jp/en/product/security_adv/index.html

Queries concerning this document can be addressed to supportcentre@emea.nec.com

Great care has been taken to ensure that the information contained in this document is accurate and complete. Should any errors or omissions be discovered or should any user wish to make a suggestion for improving this document, they are invited to send the relevant details to supportcentre@emea.nec.com

Disclaimer: Our products are subject to continuous development and improvement. Therefore additions or modifications to the products after mentioned date may cause changes to the technical and functional specifications. No rights can be derived from the contents of this document. NEC Nederland B.V. and/or its respective suppliers make no representations about the suitability of the information contained in this document and related graphics published as part of the services for any purpose. This document and related graphics are provided "as is" without warranty of any kind. NEC Nederland B.V. and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this information, including all warranties and conditions of merchantability, whether express, implied or statutory, fitness for a particular purpose, title and non-infringement. In no event shall NEC Nederland B.V. and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortuous action, arising out of or in connection with the use or performance of information available from the services. This document and related graphics published on the services could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein. NEC Nederland B.V. and/or its respective suppliers may make improvements and/or changes in the product(s) and/or the program(s) described herein at any time. The example companies, organizations, products, domain names, e-mail addresses, logos, people, places and telephone numbers depicted herein are fictitious. No association with any real company, organization, product, domain name, e- mail address, logo, person, place or telephone number is intended or should be inferred.


Revision History NEC Product Security Advisory

Vulnerability in Apache Log4j Libraries Affecting NEC Enteprise Solutions Products

  • Publish Date: 2021-12-16
  • Revision: 1.1

Summary

On December 9, 2021, the following vulnerability in the Apache Log4j Java logging library affecting all Log4j v2 versions prior to 2.16.0 was disclosed:

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker-controlled LDAP and other JNDI related endpoints.

NEC is also aware of recently identified Apache Log4j vulnerability: CVE-2021-45046: Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern vulnerable to a denial-of-service attack. NEC is investigating any potential product exposure related to this vulnerability.

A description of this vulnerability can be found on the Apache Log4j Security Vulnerabilities page.

Affected Products

NEC is investigating its products to determine which products may be affected by this vulnerability. NEC  will update this advisory as the details become available.

Any product not listed in the Products Under Investigation or Vulnerable Products section of this advisory are to be considered not vulnerable. This is an ongoing investigation, as such be aware that products that are currently considered not vulnerable may subsequently be considered vulnerable as additional information becomes available.

Products Under Investigation

The following products are under investigation to determine if they are affected by this vulnerability.

3C UCM

UCM 10.0.0.14 may be vulnerable in OpenFire services which are wrapped by 3C code. Log4j version included in Open Fire 4.5.1 is 2.11. Other parts of UCM have log4j but are all version 1.x, not vulnerable. UCM 10.1 is vulnerable but not yet released and will be fixed prior. Open Fire still under investigation on upgrade version 2.13.

NOE - UC-SDN

log4j is used by two functions:

  • nwdoc (documentation)
  • ems (ucsdn-SV9500)

If the application does not require those components they can temporary turned off:

  • systemctl stop oe-kibana
  • systemctl stop oe-elasticsearch
  • systemctl stop oailinkd
  • systemctl stop emsd

and disable those services to prevent it starts if in case NOE is reboot:

  • systemctl disable oe-kibana
  • systemctl disable oe-elasticsearch
  • systemctl disable oailinkd

# ems cannot do systemctl disable, the file has to be moved out of the /etc/rc.d/init.d/ to a secure place:

  • mv /etc/rc.d/init.d/ems /root

SMART IT Servers

SMART IT SW (Express Cluster: Not Vulnerable)


Products Confirmed Not Vulnerable

The following products have been determined not to be affected by this vulnerability. This section will be updated as NEC’s investigation continues.

  • 3C UC Client
  • 3C Mobile Client
  • AT-15/AT-35/AT-40/AT-45
  • Blueprint
  • Business Connect
  • DECT
  • DT700/DT820/DT900 STD SIP
  • DT700/DT800/DT900/DT300/DT400/DT500/DT200
  • FDA
  • GT890
  • InApps
  • KIOSK
  • LMS License Management (LMS/LMC)
  • Location Gateway
  • MA4000 Expense Management
  • MA4000 System Management
  • MG-SIP, MCMG, VS32
  • MobiCall / MobiBox
  • MyCalls
  • MyCalls Call Recording
  • NEC Meeting Center (NMC)
  • OVOC
  • PCPro (SL2100/SV9100)
  • SIP@Net
  • SL1100/SL2100