EPrints and Log4Shell

From EPrints Documentation
Revision as of 10:06, 14 December 2021 by Drn@ecs.soton.ac.uk (talk | contribs) (Potential vulnerability with Coversheets/OpenOffice Bazaar plugins)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

A basic EPrints installation is not vulnerable to Log4Shell as the exploitable software (Log4j) is not required for deployments of EPrints repository software.

It is still possible that Log4j may be present on a server that hosts EPrints, if it has been installed for some other (non-EPrints related) purpose. Assuming this server is only intended for hosting EPrints repository software, in most cases (see below), it should be OK to uninstall using the operating system's package management tool:

  • RHEL/Fedora/CentOS: yum erase log4j
  • Debian/Ubuntu: apt purge liblog4j2-java

However, RHEL 7 and 8 do not have affected versions of Log4j, (and therefore neither do CentOS 7 and 8), so no action should required even if Log4j is installed. It is less clear if versions of Log4j on Ubuntu and Debian are affected.

Even, if Log4j is installed on your EPrints server, it is very unlikely to be exploitable as EPrints runs on Apache HTTP server, which does not use Java, let alone Log4j. Therefore, there should not be a means to deploy an exploit against Log4j, unless it is used by an non-EPrints related application.

Potential vulnerability with Coversheets/OpenOffice Bazaar plugins

There is one case where Log4j will be required to support EPrints functionality and this is to provide coversheeting of PDF documents. This is due to Log4j being a dependency of OpenOffice (or LibreOffice), which is used by EPrints to convert your coversheet template into a PDF, which can be attached to the original PDF.

OpenOffice/LibreOffice will run as as a service on its own TCP port your server, so EPrints can connect to it and request the coversheet template be converted. If OpenOffice/LibreOffice's TCP port is accessible beyond your server, then there is a small chance this could be exploited by Log4Shell. Your organisation's firewall would likely block access to this TCP port beyond your organisation's network. However, to be extra secure, it is worth considering blocking remote access to this TCP port on your server's own firewall.