Apache Log4j Vulnerability CVE-2021-44228 - How does it affect Matlab?

Regarding the Apache Log4j Vulnerability CVE-2021-44228. How does it affect these software products:

1. Regular locally installed Matlab (Mac, PC, and Linux). All versions : current, plus old/historical.
2. MATLAB online (web-based version of MATLAB)
3. The MATLAB MCR runtime library (needed to run standalone executables someone compiled with the MATLAB Compiler Toolbox)
4. Installers for any Mathworks software product.

MATLAB uses log4j < v2.15

Will you provide a patch, if one is needed?

[Walter Roberson]

Very few of the volunteers who answer questions here can speak for Mathworks.

This is something that should be raised with Mathworks Support.

[Jonathan]

But it would not hurt if they were to make a public statement on their websites that was easily discroverable.

At least we received this through a support ticket:

I am writing in reference to your Technical Support Case #xxxxxxxx regarding 'Apache Log4j Security Vulnerabilities'.

This is the official response from MathWorks:

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

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

MathWorks Desktop and Server Products

No general release desktop or server products include the affected versions of Log4j. This includes MATLAB, Simulink, Stateflow, MATLAB Production Server, MATLAB Web App Server, MATLAB Parallel Server, Polyspace Access Server, Road Runner, and any toolboxes or blocksets for any of these.

MathWorks Online Applications (link)All online applications that use the vulnerable version of Log4j have been patched with officially suggested mitigations. After investigation, we found no evidence that the vulnerability has been exploited on any of our systems.

[Brandon Purnell]

What is the newest version of Matlab we can use that does NOT include a vulnerable version of Log4j?

[Lars Gregersen]

There aren't any versions of Matlab that is affected by this particular bug.

[Denverli koye]

I think also. i dint get the exact your question

[Craig Richardson]

Is this still the case in 2024? Are there still no versions of Matlab that are affected by log4j?

If so, please release an updated document that reflects that information.

Answer 1

[Sebastian]

MathWorks has published the following in the Trust Center (version 3 of 2021-12-18):

MathWorks Response to CVE-2021-44228 and CVE-2021-45046 Apache Log4j vulnerabilities

Security researchers disclosed the following vulnerabilities in the Apache Log4j Java logging library:

• CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker-controlled LDAP and other JNDI related endpoints
• CVE-2021-45046: the fix for CVE-2021-44228 was incomplete in certain non-default configurations.

MathWorks Product Security promptly conducted an assessment across the code base for desktop, server and online applications and determined that MathWorks customers do not need to take any action related to MathWorks products and online applications:

MathWorks Desktop and Server Products

None of MathWorks general release desktop or server products include the affected versions of Log4j and so do not contain the CVE-2021-44228 or CVE-2021-45046 logging vulnerabilities.

MathWorks is not aware of any exploitable vulnerabilities in the log4j framework used in any of our general release desktop or server products.

MathWorks general release desktop or server products includes MATLAB, Simulink, Stateflow, MATLAB Production Server, MATLAB Web App Server, MATLAB Parallel Server, MATLAB Online Server, MATLAB Runtime, MathWorks Product Installer, MATLAB Runtime Installer, all Polyspace products, RoadRunner and any toolboxes or blocksets for any of these. In addition, this includes all previous general releases such as R2021b, R2021a, R2020b, R2020a, and so on.

MathWorks Online Applications

All online applications have been patched with officially suggested mitigations. After investigation there was no evidence that the vulnerability had been exploited on any of our systems.

Continuing Activities

MathWorks Product Security will continue to monitor this specific set of issues for their potential impact on our products.

See here for the full document: https://www.mathworks.com/content/dam/mathworks/policies/mathworks-response-to-cve-2021-44228-log4j-vulnerability.pdf

[Marco De Bona]

Could you specify if this assesment is valid to past releases?

[N/A]

Please confirm if this is also valid for earlier releases of Mathworks products. Thanks in advance!

[Sebastian]

Yes, this is also valid for earlier releases of our products.

[Viqar]

We use Matlab Compiler Runtime for some programs (v716 and others), and there is clearly a "java/javaext" folder that includes log4j.jar. Looking at the file more carefully, it seems to be revision 1.2. So is the more detailed explanation that log4j-1.2 is unaffected? Thank you for clarifications.

[Walter Roberson]

All versions prior to 2.15 are affected, so 1.2 must be affected.

[Jia Lin Hu]

The reports: https://nvd.nist.gov/vuln/detail/CVE-2021-44228 and https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228

only mention Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 as (confirmed) affected.

There are sites mentioning that "log4j version 1.x" versions (still being investigated for now [JNDI in config]):

https://nullsec.us/log4j-log4shell/

https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/

[creepydog]

There's some confusion here.

• The critical vulnerability CVE-2021-44228 only mentions versions 2.x.
• There's another vulnerability CVE-2021-45046 which says that the fix (log4j.jar v2.15) to the first vulnerability wasn't complete under certain non-default configurations (fixed by v2.16).
• There's a third vulnerability CVE-2021-4104 which applies to log4j.jar 1.2 but only if it is configured to use JMSAppender (which it does not by default). See http://slf4j.org/log4shell.html.

@Viqar: Yes, there's the log4j.jar (v1.2.15) in "java/jarext". JMSAppender.class is included in that jar file (unzip it, find it in org/apache/log4j/net/JMSAppender.class). But is it configured to be used? In some of my Matlab installations I found configuration files (toolbox/compiler_sdk/mps_clients/java/log4j.properties), but those do not include JMSAppender. So it seems (!) to me that Matlab is unaffected by the vulnerability.

Still, I support your request to get some more (detailed) clarification from The MathWorks.

[Sebastian]

No general release desktop or server products are vulnerable to CVE-2021-4104 as shipped by MathWorks. MathWorks does not configure Log4j to use a JMSAppender.

[creepydog]

@Sebastian Thank you for your clarification!

[Viqar]

Thanks @creepydog for an excellent summary and @Sebastian's reply. Based on @Sebastian's reply ("as shipped by Mathworks"), it seems that "certain non-default configurations" of Matlab Compiler could be vulnerable to CVE-2021-4104, if a user (or someone else) configures JMSAppender in log4j.properties. This seems important to mention, although admittedly I have trouble seeing why someone would configure that... (intentionally).

We have Matlab Compiler Runtime in many places and Matlab (+ Compiler) in some. I didn't find the log4j.properties file anywhere in our installations, unlike @creepydog's configuration.

To mitigate some risk and test something, I just deleted the infamous JAR file on a Runtime machine, and my EXE program still ran fine, potentially indicating it wasn't used. But I'm not sure if an executable EXE would invoke JAR / Class directly or some compiled library instead.

Can Mathworks (or another expert) clarify where/when log4j.properties is included in an installation, and also what files/dependencies are used in an EXE build intended for use with Matlab Compiler Runtime? Is my "delete the JAR" a good approach, useless or overkill?

Thanks again.

[Marc Compere]

Hello @Sebastian, thank you for the clarity.

But the official mathworks statement lacks enough speicifc detail or references to be satisfying.

The Apache maintainers of Log4j have posted a summary and indicate the vulnerability is (currently) isolated to version 2. Log4j v1.x is not affected.

Their summary is here: https://logging.apache.org/log4j/2.x/security.html

It seems that Matlab uses Log4j v1.x and thus is not directly affected.

But it's a serious concern and I've located log4j files on my local installation of Matlab R2021a. This is what it looks like on my machine:

/usr/local/MATLAB/R2021a/java/jarext/slf4j/slf4j-log4j12.jar contains log4j files
/usr/local/MATLAB/R2021a/java/jarext/aps_impl/pubsub_impl_java/pubsub_impl.jar contains log4j files
/usr/local/MATLAB/R2021a/java/jarext/log4j.jar contains log4j files
/usr/local/MATLAB/R2021a/java/jarext/lais_server_impl/lais_server_impl.jar contains log4j files
/usr/local/MATLAB/R2021a/java/jarext/epsnotificationclient_impl/epsnotificationclient_impl.jar contains log4j files
/usr/local/MATLAB/R2021a/java/jarext/commons-logging.jar contains log4j files
/usr/local/MATLAB/R2021a/java/jar/services.jar contains log4j files

The NIST link is an excellent reference.

Referencing the Log4j maintainer's link would instill greater confidence, at least for me.

MDC

[Evi Vanoost]

It seems there are now other exploits for both 2.16 and now even 2.17 in the last 48 hours. Log4j v1 is severely outdated, open to similar exploits and won't be fixed.

Moreover, MATLAB says right in the documentation it is using Log4j through SLF4j API.

https://www.mathworks.com/help/mps/java/java-client-logging.html

Every scanner is picking up MATLAB at this point having Log4j embedded. Moreover, due to the ever-changing language, every version from 2014a onwards is still in common use across web servers and other software, but the statement only vaguely states that the current versions aren't affected without telling us how they mitigate the issue.

[Jeremy]

@Sebastian,

What portions of MATLAB use Log4j? Is it possible to remove or update that jar file from a desktop installation without adverse effects? My security team would be very happy to have an actual remediation rather than written assurances.

Thank you

[Walter Roberson]

@Evi Vanoost

If I understand correctly, the messages from Mathworks have been saying that they are not vulnerable to those two CVE... on the basis that they use a release from before the problem is documented as having the problem.

Asking the question of whether log4j in Mathworks products is "secure" is then a different question, really. And not actually the same as the answer to whether log4j shipped with various releases and products are vulnerable to any already known CVE. I suspect that given the attention to log4j that malicious people are seeking exploits against earlier log4j releases, so even if were knew that the log4j 1.x shipped with Mathworks products had already been patched to all known CVE that affected it, you can be relatively sure that new exploits are going to show up.

Because of this, it would probably be a good idea for Mathworks to (if technically true) release a statement along the line of "Here are the products that use log4j, and if you are not using those products then you can delete the .jar file" (and provide mcr for each release in which the jar has been omitted.) Close the entire attack surface rather than just relying on the fact that there is not yet a public CVE about version 1.x . You can be pretty sure that there is some exploit out there for version 1.x, in my opinion.

[Jürgen]

@Walter Roberson

How can I find out, whether my applications utilize any of the earlier versions.

If I remove it – how can I find out that my software will not utilize this functionality under yet unforeseen conditions?

The question turns out, to be related to another question I asked myself last week:

How can I find out the code-dependencies in my ‘projects’.

In previous obligations where I used more classical languages the underlying project tool and the necessity to compile ensured such structural coverage at least to my expectations as device-engineer/physicist. Additional code analyzer tools could be used to visualize and track it graphically.

Could anyone give me an advice what the best way is, to do it with Matlab. I know several options in Matlab, but maybe not deeply enough. Maybe there is a ‘good all in one’ overview-article how to do it in the latest releases – to get a good project-feeling?

[Walter Roberson]

Mathworks tells me that I can check the log4j version by cd'ing matlabroot and using

unzip -p java/jarext/*log4j*.jar META-INF/MANIFEST.MF

Based upon the checks I did (with the toolboxes I have), it looks to me as if ROS (Robot Operating System) actively uses log4j, and that genicam drivers do as well. Beyond that... well, I am concerned about the toolbox/parallel/bin/util/msa_pct.ini which might be implying that some or all of Parallel Computing Toolbox relies upon the utility.

Answer 2

[QMA]

FYI.. when you download the latest version for installation, there is reference to log4j in 2021b:

./Downloads/MathWorks/R2021b/2021_12_03_21_37_17/archives/3p/log4j_common_1621039475.enc

./Downloads/MathWorks/R2021b/2021_12_03_21_37_17/archives/3p/log4j_common_1621039475.xml

[Lars Gregersen]

Check the version numbers and compare with

https://nvd.nist.gov/vuln/detail/CVE-2021-44228

[Walter Roberson]

/3p means "Third party". So some third party product might include it.

[Walter Roberson]

That log4j_common is responsible for installing

filename = fullfile(matlabroot, 'java', 'jarext', 'log4j.jar')
ls(filename)

References in files that I found on my system. I do not have all toolboxes and official support packages installed, so there might be additional instances

./sys/ros1/maci64/ros1/share/ros/config/rosconsole.config:log4j.logger.ros=INFO

./sys/ros1/maci64/ros1/share/ros/config/rosconsole.config:log4j.logger.ros.roscpp.superdebug=WARN

./sys/ros1/maci64/ros1/share/roslisp/s-xml/test/ant-build-file.xml: <include name="log4j-core.jar" />

./sys/ros1/maci64/ros1/share/roslisp/s-xml/test/ant-build-file.xml: dir="${rsrc}/log4j"

./sys/ros1/maci64/ros1/share/roslisp/s-xml/test/ant-build-file.xml: includes="log4j.properties" />

./sys/ros1/maci64/ros1/share/roslisp/s-xml/test/ant-build-file.xml: <unjar src="${lib}/log4j-core.jar" dest="${build}" />

./sys/ros1/maci64/ros1/share/roslisp/s-xml/test/ant-build-file.xml: <unjar src="${lib}/log4j-core.jar" dest="${build}" />

./sys/ros1/maci64/ros1/share/roslisp/s-xml/test/ant-build-file.xml: <include name="log4j.properties"/>

./sys/ros1/maci64/ros1/share/roslisp/s-xml/test/ant-build-file.xml: <include name="org/apache/log4j/**"/>

./sys/ros1/maci64/ros1/share/roslisp/s-xml/test/ant-build-file.xml: <include name="log4j-core.jar" />

./toolbox/parallel/bin/util/msa_pct.ini:java/jarext/log4j.jar

./toolbox/imaq/imaqextern/drivers/maci64/genicam/GenICam_v3_1_0/log/config-unix/DefaultLogging.properties:log4j.rootCategory=ERROR, Console

./toolbox/imaq/imaqextern/drivers/maci64/genicam/GenICam_v3_1_0/log/config-unix/DefaultLogging.properties:log4cpp.appender.Console=org.apache.log4j.ConsoleAppender

./toolbox/imaq/imaqextern/drivers/maci64/genicam/GenICam_v3_1_0/log/config-unix/DefaultLogging.properties:log4cpp.appender.Console.layout=org.apache.log4j.PatternLayout

./toolbox/matlab/compatibility/codeAnalyzerChecks.json: "package" : "org.apache.log4j",

./toolbox/matlab/compatibility/codeAnalyzerChecks.json: "org.apache.log4j"

./mcr/toolbox/parallel/bin/util/msa_pct.ini:java/jarext/log4j.jar

I think the .json is just for code completion suggestion purposes, rather than being an invocation of the code.

sys/ros1 is part of ROS (Robot Operating System) toolbox, https://www.mathworks.com/help/ros/index.html

Genicam is a camera interface, https://www.mathworks.com/help/imaq/genicam-gentl-hardware.html . I do not have the Image Acquistion Support Package for GeniCam Interface installed, but I still have those driver files.

I just opened a support case reporting these files.

Answer 3

[Shahed Sherkat]

How about vulnerabulut to CVE-2021-4104 ?

I have found 4 potentially vulnerable files in my Matlab R2017b.

[?] Found CVE-2021-4104 (log4j 1.2) vulnerability in C:\Program Files\MATLAB\R2017b\java\jarext\aps_impl\pubsub_impl_java\pubsub_impl.jar, log4j 1.2.17

[?] Found CVE-2021-4104 (log4j 1.2) vulnerability in C:\Program Files\MATLAB\R2017b\java\jarext\lais_server_impl\lais_server_impl.jar, log4j N/A - potentially vulnerable

[?] Found CVE-2021-4104 (log4j 1.2) vulnerability in C:\Program Files\MATLAB\R2017b\java\jarext\log4j.jar, log4j 1.2.15

[?] Found CVE-2021-4104 (log4j 1.2) vulnerability in C:\Program Files\MATLAB\R2017b\mcr\toolbox\matlab\connector\jar\3p.jar, log4j 1.2.17

Please adivce.

Thanks,

Shahed

[Sebastian]

Please see this earlier comment regarding CVE-2021-4104.

[Shaochieh Young]

Sebastian,

The US government maybe force to uninstall applications if the unsupposed version of Log4j is not implented to the software.

[Walter Roberson]

@Shaochieh Young

I don't think the US government has any authority in my country. I am not even clear that it has the authority to require such a thing inside the USA.

It does plausibly have authority to tell US Federal Government departments and US Federal Government Contractors that they must remove such software for security reasons.

[Nicholas Clark]

In addition to CVE-2021-4104, now potentially included are: CVE-2019-17571, CVE-2020-9488, and CVE-2022-23302.

Answer 4

[Steve Peppas]

Hey guys, i have found a convenient "hack" to mitigate the log4j vulnerability if you feel unsafe like me. Here is what i did:

1) Downloaded log4j-core-2.17.2 and added it to matlab/java/jarext folder.

2) Added it to the classpath.txt which is found in matlab/toolbox/local.

3) Deleted the previous log4j.jar in matlab/java/jarext.

4) Downloaded the log4j-1.2-api-2.17.2 logging bridge, added it to matlab/java/jarext and renamed it to log4j.jar

5) Last, downloaded the log4j-api-2.17.2, copied the logging folder in it and put it at the above log4j.jar in org.apache path.

I am using Ubuntu 20.04.4 OS.

[fyin]

Hi, I solved this problem. Thank you, guy.

[Vincent Sherart]

Please excuse the java noob question, but I know very little about java programming. On the last step above, step 5, I get as far as using the jar utility to extract the contents fo the log4j-api*jar file, but I'm confused about section that says put logging folder above log4j.ar in org.apache path. Can someone provide more detail on this step?

For example, if I have MATLAB installed in /opt/MATLAB/R2021a, does the logging directory go somewhere in the /opt/MATLAB/R2021a/java dir structure?

Thanks,

Vince

[Steve Peppas]

Hey Vince, every .jar file is like a .zip file, meaning you can extract the files, copy and paste them.

So, for Step 5, copy the logging folder inside log4j-api-2.17.2.jar and paste it in the (new) log4j.jar in org/apache path inside log4j.jar.

Hope this is clear enough.