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 indeed uses log4J for logging but in the CURRENT Delft-FEWS code the call to the suspicious log4J method is NOT used and the Delft-FEWS code has implemented its own - non configurable version - of this method. The option to use this suspicious method is therefore NOT possible. The Delft-FEWS code even prevents this. In addition, all supported Delft-FEWS versions also use a higher java-version than the one mentioned in the news.
This means that all supported Delft-FEWS versions from 2018.02 and up are NOT directly affected by the vulnerability in Log4J.
We realize that this security issue leads to general concerns. From a Delft-FEWS perspective there is no immediate threat, but we will highlight the no-regret measures that you can implement on the short term. Furthermore, we will share our follow-up plans for upgrading to a higher version of Log4J.
Delft-FEWS Product Management
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.
Apache's guidance
Initially, 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)
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) 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 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
If you have any other questions concerning the above, do not hesitate to contact us.
Delft-FEWS Product Management
