Thread "Apache log4j security vulnerability"

Dear all,

I can see in the source code of ILIAS that log4j is used in different occasions. Is there any advise on what to do regarding the current thread with the log4j security vulnerability? (Perhaps just turn of loggin for now?)

More info:
Search ong github: https://github.com/ILIAS-eLearning/ILIAS/search?q=log4j
Apache foundation: https://logging.apache.org/log4j/2.x/security.html
More info: https://www.kaspersky.com/blog/log4shell-critical-vulnerability-in-apache-log4j/43124/

Kind regards,

Robert Kuunders

Most of the references to log4j in the source-code of included libraries are not used in ILIAS. 

The only Java-Service in ILIAS at all that is using log4j is ilserver for Lucene indexing and PDF Generation as far as i know. 

This service is locally use by ILIAS and not reachable via network from the ourside (it is only used via RPC Calls from ILIAS itself). For our instances this service is either bound to localhost or reachable on a port which is firewalled from the outside and therefore only reachable by the ILIAS php workers/Webservers.

So far this service of course should be updated to use fixed library or mitigations described but no immediate risk now.

Having debugged the ilServer to solve some issues we have indexing, I can assure you, that ILIAS it not vunerable to this bug.

ilServer isself uses log4j 1.2, which is not affected (only log4j 2.x is), so there is no need to update. There would be no update to the lib anyway, since it is EOL 2015.

The conclusion Ralf draws, the since ilServer is not connected to the network directly would not be affected by this issues is wrong. If running in debug mode (I have not check the others), it does log the query string, which is passed in through the ILIAS php workers. Thus searching for the jndi://ldap string would trigger this bug.

Cheers,
Pascal

Coyp and paste from https://logging.apache.org/log4j/2.x/security.html

"Please note that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes."

How do you come to the conclusion that there is no need for further action?

Best regards
Carsten

P.S. I removed log4j-1.2.15.jar from the server and at least PDF certificate generation still works (we do not use Lucene).

Hi Carsten,

the Atlassian FAQ states, that the Atlassian products, which are using the same version are not affected by this bug. There might of course be other issues or CVEs (we had other issues with both PDFBox and POI librarys)  in the ilServer because the usage of old (long unmainted) libs.

Removing the jar itsself does not work. This file is only used when build ilServer. You would need to remove the class files from the ilServer.jar itsself. And looking at the code, this would cause ilServer to fail direcly at startup.

Cheers,
Pascal

We do use lucene and PDF generation. We also use Apache2 as a web server, we do not use the log4j Apache2 package, you can use this command to check if it is installed on your system:

dpkg -l | grep apache-log4j2 

we found the following log4j files im ILIAS Root:

ILIAS/Services/WebServices/RPC/lib/jars/log4j-1.2.15.jar
ILIAS/libs/bower/bower_components/yui2/src/common/tests/functional/yui/src/test/resources/log4j.properties
ILIAS/libs/bower/bower_components/yui2/src/common/tests/functional/yui/yui/src/test/resources/log4j.properties

as @rschenk said, the service runs locally, you can check it with this command:

netstat -tulpn | grep LISTEN | grep java

tcp        0      0 127.0.0.1:11111         0.0.0.0:*               LISTEN      33764/java                                       

it would be helpful if the ilias securtiy team, can confirm that this vulnerability do not effect ilias.

Kind Regards

Looking for individual jars does not have any effect of ilServer. The build process (take a look at the ant file "build.xml") builds a fat jar, that includes all the deps. To find the class, you need to take a look at ilServer.jar with:

unzip -tl ilServer.jar | grep log4j

There you will see als the class files include from log4j 1.x

And as I sad earlier, the port and host where the services runs does not make any difference in this case, as it gets passed in the user input from the search input field, which gets logged e.g. here. A log4j2 would be exploitable at this point.

Cheers,
Pascal

Thank you all for the input. 

So I guess the safest action right now is disabling Lucene search completely, especially in public environments (like this website?) untill we know for sure that the 'old' log4j 1.x is not vulnerable to this hack. 

Perhaps the ILIAS security team can confirm this advice, like Fadi Asbih suggested?

Robert

Quoted from https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126

log4j 1.x does not support lookups. I also could not find any other reference to JNDI in the log4j 1.x source code. So, no guarantees but it looks like 1.x is not impacted by this vulnerability.

CORRECTION: log4j 1.x contains a JMS Appender which can use JNDI. So I would say that, yes, log4j 1.x is also impacted by this vulnerability

Update (2021-12-11 09:09 JST): according to this analysis by @ceki (the author of log4j 1.x), Log4j 1.x is not impacted, since it does not have lookups, and the JMS Appender only loads Strings from the remote server, not serialized objects.

Update (2021-12-12 10:09 JST): according to this analysis by @TopStreamsNet, strictly speaking, applications using Log4j 1.x may be impacted if their configuration uses JNDI. However, the risk is much lower.


Affected or not, that is the questions here ;-)

Responses from TB or component maintainer would be really appreciated.

Best regards
Carsten

Since there is still no "official" statement from ILIAS side.

This is from BSI. Latest Version is available here: https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.html

"Update 2: Die Log4J Versionen 1.x sind von der aktuellen Schwachstelle nach aktueller Kenntnis nicht betroffen [GIT2021d]. Die Version 1.x wird, auch wenn sie noch in diversen Produkten eingesetzt wird, nicht mehr vom Hersteller unterstützt. Sie ist End-of-Life und durch andere Schwachstellen verwundbar. Daher sollten auch noch eingesetzte Log4J Versionen 1.x ebenfalls auf eine nicht-verwundbare Version 2.x aktualisiert werden."