Is Specify 6 affected by Log4Shell?

[ben3000]

Log4j is affected by a high priority vulnerability that also affects some downstream projects, including Solr.

Is Specify 6 affected by this vulnerability?

[kurankat]

Looking at the code, Specify6 uses Log4j in quite a few places:

https://github.com/specify/specify6/search?q=log4j

The latest release is from 2019, so I'd say it's a good bet that yes, it is almost certainly affected. Developer silence is worrying in the 5 months since this issue was raised.

More worryingly, Specify7 includes an instance of Specify6, and usually reachable by the world, so I would be concerned that it, too, is affected.

[benanhalt]

In December an email was sent to all Specify Consortium members. We should have also included that information in this issue. I'm reproducing the text of the email below for future reference:

Specify Consortium Members:

On December 9, a serious vulnerability in the Java-based logging package Log4j was disclosed. This vulnerability allows an attacker to execute code on a remote server. The Specify platform impacted by this vulnerability is the Specify Web Portal. The Specify Web Portal uses the Apache Solr search engine which uses the Log4J package.

Here is the vulnerability page for Solr: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228

Specify 7 (not the Web Portal) uses a library called Jasper Reports that is needed by the Report Runner service that includes the Log4j library. The Report Runner service only communicates directly with Specify 7, making its risk to be compromised very low. We will need an update from Jasper Reports to eliminate this low risk issue completely from Specify 7. Here is the Jasper Reports security page: https://community.jaspersoft.com/questions/1190676/cve-2021-44228-log4j-vulnerability

Specify 6 is not affected by the vulnerability. The version of Log4j that Specify 6 includes is not vulnerable to this exploit.

If you are running the Specify Web Portal at your institution, mitigation of the issue is to modify the solr.in.sh file as described on the Solr page linked above. The file is found in the webportal-installer/build/bin directory after the Specify Web Portal has been built. After modifying the file, the Web Portal Solr service has to be restarted. When updating the portal with new exports, it should be confirmed that the modification remains in place as the build directory may be overwritten by the update process. The Specify engineering team will update the Web Portal builder to use Solr 8.11.1 when it becomes available which eliminates the issue. We have updated instances of the Web Portal we host for member institutions using the Specify Cloud service.

Please contact support@specifysoftware.org if you are running the Specify Web Portal locally and have questions about this vulnerability and fix.

Jim Beach

[kurankat]

Thanks for adding this @benanhalt,

Given that both Specify 6 and Specify 7 are open source software, it's good to have it here, as a letter sent to the consortium is not publicly available information.

Knowing whether the current version is vulnerable, and what mitigations might exist if that's the case, is critical information for people or institutions assessing the software with a view to potentially using it (and deciding whether to join the Consortium). It's not a good look when critical vulnerability information is only disseminated to those who are already members of the Consortium.

It would be useful, for example, to know whether the specifyconsortium Docker images have had the described mitigations applied to them. At least the Specify 6 service image has not been updated for 8 months...

[misilot]

Any chance the log4j jar file could replaced with https://reload4j.qos.ch/?

As we are getting dinged by our security audit.