Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Updated: 22/12/2021

Statement

Friday, 10 December 2021, our OWASP-scan alerted us to a vulnerability in Log4J, a commonly used open-source library for java applications. https://nvd.nist.gov/vuln/detail/CVE-2021-44228

...

Delft-FEWS Product Management13th of December 2021

More technical details

Delft-FEWS versions 2018.02 and higher

Delft-FEWS and its components are using Log4j 2.11.1. This is true for the Operator Client, Forecasting Shell Server, Master Controller, Delft-FEWS Webservices, Admin Interface, Database proxy, Open Archive (including Elastic Search). As mentioned, the suspicious method call is replaced in the Delft-FEWS code with our own implementation. The method called 'PatternLayout' is the problem in Log4j and our code uses its own implementation called 'FastLayout' preventing the malicious JNDI lookup from being used.

Java option/version aspects

Apache's guidance

Initially, according According to Apache’s guidance, in releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. This, however, has no impact on Delft-FEWS at all. In a later statement Apache indicated to remove the JNDI lookup class from the log4j-core jar, since the system property was not sufficient (https://logging.apache.org/log4j/2.x/security.html)

Log4j Upgrade to 2.15: New basebuilds will be made available for all supported Delft-FEWS versions

A Log4J upgrade is available and is necessary to prevent security/vulnerability-scanning tools to produce false alarms (for Delft-FEWS). This 2.15 version needs to be 'packed and distributed' with all other java code of Delft-FEWS.

In the development version of Delft-FEWS (leading to 2022.01) we have replaced the Log4j 2.11.1 and upgraded it to the latest version (2.15). The same is true for Delft-FEWS 2021.02 which is about to be released.

For all other supported Delft-FEWS versions (2019.02 and higher) Deltares will provide a new base-build (+patch) in the next few days. This new base-build will contain Log4J version 2.15. If you are running an older version, please contact the Delft-FEWS helpdesk at fews.support@deltares.nl.

...


Although it is technically possible to remove this class from the Log4j-cor.jar file, Delft-FEWS may start to complain since the /bin folder is checked according to the file-list.txt at startup. This file is also available in the /bin folder of Delft-FEWS. If you decide to remove the mentioned classes from the log4j 1.2.jar anyway,  please remove that file-list.txt file too, then. This means that you have to do that for every location a /bin folder is present in your system(s). 

We would like to stress that this class-removal is NOT necessary and we strongly recommend to wait for the updated Delft-FEWS base-builds of your version in use which are to be distributed soon.

Older Delft-FEWS versions (2017.02, 2017.01, 2016.02...)

Although not supported anymore, we are aware that some older Delft-FEWS versions are in use. 

All older Delft-FEWS versions before 2018.02 use log4j version 1.x. which does not contain the vulnerable class (JNDI lookup). Also the JMSAppender is not used.

Log4j version 1.x is end-of-life, so we strongly recommend to upgrade to a supported version of Delft-FEWS (at least 2018.02 but preferably higher)

Model adapters (maintained by Deltares)

Model adapters may use the log4j 2 libraries as well. Where applicable, Deltares has upgraded the log4j libraries to version 2.17 and model adapter packages are distributed on request as part of the mitigation plan (see below).

The following model adapters have been upgraded: HEC-HMS, Kanali, Ribasim, SMAP, SWAN, SWMM and WANDA. The Delft3D model adapter is part of the Delft-FEWS code so this one is automatically part of the upgraded packages (see mitigation plan below).

All other model adapters we are aware of do not use Log4j version 2.x (but log4j 1.x so they are not affected). Upgrading these model adapters to the latest Log4j library means a lot more work and will be considered early 2022.

Current mitigation plan: Log4j Upgrade to 2.17: New basebuilds will be made available for all supported Delft-FEWS versions

Another vulnerability was fixed in a newly released version of Log4j. For all supported Delft-FEWS versions (2019.02 and higher) e a new base-build and patch will be made available, using Log4J version 2.17.

The earlier mentioned base-build with version 2.15 will not be released.With  With the new base build and patch installed the scanning tools will not be flagging Log4j anymore.

New packages of the Master Controller, Admin Interface, OC/FSS binaries, Delft-FEWS Webservices, ArchiveServer (including updated versions of ElasticSearch and Thredds) for all supported Delft-FEWS versions are in the making.

The same is true for the latest versions of model adapters maintained by Deltares.


If you/your organisation would like to receive the updated base-build/patch of your version, let us know! Please, send an e-mail to fews.support@deltares.nl

...

Delft-FEWS Product Management
13th of December 2021