perfSONAR Announcements

[Mark Feit <>]

As many are aware by now, a severe remote code execution vulnerability in Log4j [1] was announced late last week.  As it is causing quite a stir, we’ve done a more-complete audit of where it’s used in perfSONAR and thought it would be worth making a formal announcement as a follow-up to the thread on the perfsonar-users mailing list. [2]

 

The use of Log4j in perfSONAR is confined to Cassandra (used by Esmond), MaDDash and the Lookup Service.

 

Cassandra uses Log4j 1.x, which does not have this vulnerability.  With the replacement of Esmond in perfSONAR 5.0, Cassandra will no longer be required and will no longer be installed.

 

MaDDash uses Log4j 1.x, which does not have this vulnerability.  We are aware that Log4j 1.x has its own set of pitfalls and will upgrade it to a current, patched version in the 5.0 release or migrate to some other library.  We have identified a single instance where data provided by a client is directly logged as debug.  This data will not be logged if MaDDash is left in its default configuration.

 

The Lookup Service uses Log4j and is vulnerable.  The global lookup service operated by the perfSONAR project has been patched to disable lookups in the service itself and the ElasticSearch [3] server.  Sites running private lookup servers should take the steps described at https://github.com/esnet/simple-lookup-service/wiki/Apache-log4j-Remote-Code-Execution-vulnerability to reconfigure the software so it is no longer vulnerable.

 

Please drop us a line if you have questions or comments.

 

 

Links:

[1]  https://www.cve.org/CVERecord?id=CVE-2021-44228

[2]  https://lists.internet2.edu/sympa/arc/perfsonar-user/2021-12/msg00001.html

[3]  https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476