Hi all,
Please can you let me know whether Moodle is impacted by the Log4J Vulnerability?
Moodle is not affected.
(The J in log4j is 'Java', which is a completey different computer language than PHP, which is the computer language used for Moodle.
Some other things which some people use in relation to Moodle - for example, if you use Moodle Global Search with a Solr search back-end, then you may need to check that, but that is outside Moodle.)
(The J in log4j is 'Java', which is a completey different computer language than PHP, which is the computer language used for Moodle.
Some other things which some people use in relation to Moodle - for example, if you use Moodle Global Search with a Solr search back-end, then you may need to check that, but that is outside Moodle.)
Thank you Tim
Hi Tim,
I'm doing some digging around on for log4j vunrabilities (like others).
For my own reassurance I've taken a look at the MaximaPool servlet (part of a moodle STACK question type deployment) which you authored, and can't see it makes use of log4j in any way. I assume you can confirm that?
My tomcat server which this runs in also isn't using log4j as an alternative logger, so I think I'm in the clear!
I'm doing some digging around on for log4j vunrabilities (like others).
For my own reassurance I've taken a look at the MaximaPool servlet (part of a moodle STACK question type deployment) which you authored, and can't see it makes use of log4j in any way. I assume you can confirm that?
My tomcat server which this runs in also isn't using log4j as an alternative logger, so I think I'm in the clear!
MaximaPool does not use log4j. However, Tomcat itself uses log4j internally. We run Tomcat from RHEL, and when our server people checked what RedHat were saying, it seems to be safe. (But, like all server software, worth keeping your Tomcat install up-to-date.)
I've spent some time looking at this more carefully. The tomcat docs (https://tomcat.apache.org/tomcat-8.0-doc/logging.html) and everywhere else I read say that the default logger for Tomcat isn't log4j. It has it's own internal light weight logger. log4j is a very popular resplacement for this which can be added to the out the box tomcat install. Luckily, my install uses the default logger. Either way, thanks for the confirmation about MaximaPool, was 99.9% sure that was the case, but wanted reassurance I guess.
And also worth noting that java is entirely unrelated to JavaScript.
Just to clarify Tim's point further, the core Moodle LMS is unaffected by log4shell, because it does not use log4j (or java). Of course any third party content (plugins, themes, search engines or other software etc set up on your infrastructure) would need to be verified by system administrators to confirm whether those may be affected in their instance.
In a separate discussion, Michael Taggart does appear to have confirmed that Tim's example of Solr search's backend is a valid risk, so that is one example where sites utilising it should investigate and patch as necessary.
Thanks Michael, as you noted, things to watch out for in plugins are Java and jar files. When I did a search on my system, I came up with an old plugin that made use of Red5 back in the day when it was using log4j (which is over 10 years ago). At one point, back in the CVS days, I liked the idea of being able to search all of the plugins for particular vulnerabilities. This would require a bit of scripting but I think the community could probably identify the plugins that might potentially be impacted and flag them. Again, just to be clear, Red5 reports that the current version is not affected by the log4j vulnerability. If folks have any questions about a particular plugin, it never hurts to ask. I would be interested in seeing a list of plugins that would require Java to be installed on a server and then go through that list and ensure that they are unaffected. Peace - Anthony