log4j / log4shell CVE-2021-44228 vulnerability

[Ludee]

Dear developers,

while we were searching for affected software, we found that Protégé is using log4j library. I'm currently running Protégé Portable Version 5.5.0 stable which includes log4j-over-slf4j.jar.

It seems like this specific version is not affected:

As log4j 1.x does NOT offer a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228.

http://www.slf4j.org/log4shell.html

Could you please verify and communicate to the user community. Thank you and looking forward to hear from you!

[graybeal]

Lorenz Buehman (thank you!) reports on the mail list (lightly edited for readability):

Ok, so I had a look at the Protege 5.50 distribution as well as the current Github code:

mvn dependency:tree | grep log4j

shows

+- org.slf4j:log4j-over-slf4j:jar:1.7.12:compile

as a dependency. So this is log4j 1.x. According to https://www.slf4j.org/log4shell.html

As log4j 1.x does NOT offer a JNDI look-up mechanism at the message level, it does NOT suffer from CVE-2021-44228.

indeed, they also mention another possible, though harder, way to get access to the JNDI However, log4j 1.x comes with JMSAppender which will perform a JNDI lookup if enabled in log4j's configuration file, i.e. log4j.properties or log4j.xml.

There won't be an update of log4j 1.x afaik, so the suggested way is to

make job of the attacker even harder by removing JMSAppender altogether from log4j-1.2.17.jar

You can use for Protege then

zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class

I checked the distributed log4j

unzip -v bundles/log4j-over-slf4j.jar  
Archive:  bundles/log4j-over-slf4j.jar 
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name 
--------  ------  ------- ---- ---------- ----- --------  ---- 
       0  Stored        0   0% 2015-03-26 21:57 00000000  META-INF/ 
     712  Defl:N      326  54% 2015-03-26 21:57 a3b89576  META-INF/MANIFEST.MF 
       0  Stored        0   0% 2015-03-26 21:53 00000000  org/ 
       0  Stored        0   0% 2015-03-26 21:53 00000000  org/apache/ 
       0  Stored        0   0% 2015-03-26 21:53 00000000  org/apache/log4j/ 
       0  Stored        0   0% 2015-03-26 21:53 00000000  org/apache/log4j/helpers/ 
       0  Stored        0   0% 2015-03-26 21:53 00000000  org/apache/log4j/spi/ 
       0  Stored        0   0% 2015-03-26 21:53 00000000  org/apache/log4j/xml/ 
     684  Defl:N      328  52% 2015-03-26 21:53 3c3d5e6a  org/apache/log4j/Appender.class 
     857  Defl:N      401  53% 2015-03-26 21:53 08a3f14a  org/apache/log4j/AppenderSkeleton.class 
     552  Defl:N      297  46% 2015-03-26 21:53 26a04195  org/apache/log4j/BasicConfigurator.class 
    6707  Defl:N     2599  61% 2015-03-26 21:53 e8a5b30d  org/apache/log4j/Category.class 
     319  Defl:N      217  32% 2015-03-26 21:53 c2e96ce6  org/apache/log4j/ConsoleAppender.class 
     872  Defl:N      387  56% 2015-03-26 21:53 bc2da80f  org/apache/log4j/FileAppender.class 
    2075  Defl:N      992  52% 2015-03-26 21:53 459bfdfe  org/apache/log4j/helpers/LogLog.class 
     776  Defl:N      433  44% 2015-03-26 21:53 0241a0a3  org/apache/log4j/helpers/NullEnumeration.class 
     277  Defl:N      210  24% 2015-03-26 21:53 e2b7b704  org/apache/log4j/Layout.class 
    3027  Defl:N     1577  48% 2015-03-26 21:53 d9b25ace  org/apache/log4j/Level.class 
    2425  Defl:N     1201  51% 2015-03-26 21:53 3bc989bc  org/apache/log4j/Log4jLoggerFactory.class 
    1733  Defl:N      748  57% 2015-03-26 21:53 3a73cbd1  org/apache/log4j/Logger.class 
    1334  Defl:N      610  54% 2015-03-26 21:53 07f535ea  org/apache/log4j/LogManager.class 
    1351  Defl:N      662  51% 2015-03-26 21:53 e284ddb2  org/apache/log4j/MDC.class 
    1868  Defl:N      958  49% 2015-03-26 21:53 635b070a  org/apache/log4j/NDC.class 
     439  Defl:N      263  40% 2015-03-26 21:53 72df0330  org/apache/log4j/PatternLayout.class 
    2724  Defl:N     1220  55% 2015-03-26 21:53 d1e62877  org/apache/log4j/Priority.class 
    1406  Defl:N      517  63% 2015-03-26 21:53 61ce7b61  org/apache/log4j/PropertyConfigurator.class 
     963  Defl:N      470  51% 2015-03-26 21:53 1e3a5696  org/apache/log4j/RollingFileAppender.class 
     302  Defl:N      210  31% 2015-03-26 21:53 34adddc1  org/apache/log4j/SimpleLayout.class 
     320  Defl:N      234  27% 2015-03-26 21:53 4613a00e  org/apache/log4j/spi/Configurator.class 
     303  Defl:N      219  28% 2015-03-26 21:53 82fa40de  org/apache/log4j/spi/ErrorHandler.class 
     285  Defl:N      212  26% 2015-03-26 21:53 a02d1404  org/apache/log4j/spi/Filter.class 
     263  Defl:N      178  32% 2015-03-26 21:53 6c1cf2e7  org/apache/log4j/spi/HierarchyEventListener.class 
     285  Defl:N      215  25% 2015-03-26 21:53 b692581e  org/apache/log4j/spi/Layout.class 
     208  Defl:N      159  24% 2015-03-26 21:53 ace14486  org/apache/log4j/spi/LoggerFactory.class 
     914  Defl:N      437  52% 2015-03-26 21:53 1d0b27d1  org/apache/log4j/spi/LoggerRepository.class 
     303  Defl:N      219  28% 2015-03-26 21:53 65213149  org/apache/log4j/spi/LoggingEvent.class 
     160  Defl:N      138  14% 2015-03-26 21:53 21dba5a1  org/apache/log4j/spi/OptionHandler.class 
     318  Defl:N      217  32% 2015-03-26 21:53 e393d6b5  org/apache/log4j/WriterAppender.class 
    2011  Defl:N      710  65% 2015-03-26 21:53 76f16be9  org/apache/log4j/xml/DOMConfigurator.class 
       0  Stored        0   0% 2015-03-26 21:57 00000000  META-INF/maven/ 
       0  Stored        0   0% 2015-03-26 21:57 00000000  META-INF/maven/org.slf4j/ 
       0  Stored        0   0% 2015-03-26 21:57 00000000  META-INF/maven/org.slf4j/log4j-over-slf4j/ 
    1786  Defl:N      638  64% 2015-03-26 21:53 02d92e4f  META-INF/maven/org.slf4j/log4j-over-slf4j/pom.xml 
     116  Defl:N      109   6% 2015-03-26 21:53 a17ecc4b  META-INF/maven/org.slf4j/log4j-over-slf4j/pom.properties 
--------          -------  ---                            ------- 
   38675            18311  53%                            44 files

There is no such JMSAppender inside.

In a next step I run one of the CVE scanner tools that came up:

https://github.com/logpresso/CVE-2021-44228-Scanner

This tool by the way would also allow for fixing the following vulnerabilities:

Log4j v2 - CVE-2021-44228 (JndiLookup), CVE-2021-45046 (JndiLookup)
Log4j v1 - CVE-2021-4104 (JMSAppender), CVE-2019-17571 (SocketServer), CVE-2017-5645 (SocketServer), CVE-2020-9488 (SMTPAppender)

I did only a scan to verify that I didn't miss any JAR file before when I searched "manually": log4j1 stuff:

./log4j2-scan --scan-log4j1 Protege-5.5.0 
Logpresso CVE-2021-44228 Vulnerability Scanner 2.7.1 (2022-01-02) 
Scanning directory: Protege-5.5.0 (without /dev, /run, /dev/shm, /run/lock, /sys/fs/cgroup, /proc/sys/fs/binfmt_misc, /run/user/10026) 
 
Scanned 95 directories and 351 files 
Found 0 vulnerable files 
Found 0 potentially vulnerable files 
Found 0 mitigated files 
Completed in 2.13 seconds

log4j2 stuff:

./log4j2-scan Protege-5.5.0  
Logpresso CVE-2021-44228 Vulnerability Scanner 2.7.1 (2022-01-02) 
Scanning directory: Protege-5.5.0 (without /dev, /run, /dev/shm, /run/lock, /sys/fs/cgroup, /proc/sys/fs/binfmt_misc, /run/user/10026) 
 
Scanned 95 directories and 351 files 
Found 0 vulnerable files 
Found 0 potentially vulnerable files 
Found 0 mitigated files 
Completed in 2.12 seconds

Summary: so far I couldn't find any vulnerability issue with the Protege 5.5.0 release (Linux tarball)

Indeed this doesn't hold for plugins. You can run the same scanner again on your Protege distribution with all your extensions, it will scan all plugin JARs - let me know if you found any plugin that is vulnerable.

This brings up an important point with community code: none of the plugins was never curated to my understanding, it could always do bad things - as long as nobody does analyze their source code, you should almost always be careful

[graybeal]

Additional details from Philip Lord (again, thank you):

Actually, I think I agree that this isn't a problem.

log4j-over-slf4j is not actually log4j. It's a bridge that replaces log4j calls and redirects them to slf4j.

Now, confusingly, slf4j is itself an abstraction layer that passes all of its actual logging over to something else. Now, that something else could be log4j and it could be either log4j 1.x or log4j 2.x. But the distribution doesn't contain either.

I think, if someone dropped a log4j 1.x or log4j 2.x jar file into the protege classpath, then slf4j would pick this up and start to use it. So, there is a theoretical risk, but the default distribution does not use log4j. As the OWL API also uses slf4j, it has the same theoretical risk.

I am also not sure that the version numbers of log4j-over-slf4j relate to an equivalent version of log4j. If Protege were using log4j 1.x, it would be safe from log4shell but, alas, 1.x is well EOL, so has its own problems.

The Java ecosystem does seem to have got terribly complicated.

[Ludee]

Thanks for the detailed response and clarification!