Author: James Agnew, CTO
On Thursday, Dec 9, 2021, a very serious security vulnerability was reported against a widely used Java logging framework called Log4j2. This vulnerability affects many popular software packages, and potentially allows remote code execution, making it extremely serious. You can learn more about this here.
It is important to stress that Smile CDR and HAPI FHIR both use a competing framework called Logback for logging functions, and this framework is not vulnerable to this issue. Our use of the Logback framework is described here.
Smile CDR does include a library in our standard distribution that appears to be vulnerable (log4j-api-2.11.1). An audit reveals that this library is included for compatibility reasons only and is not used for any primary logging, meaning that it should not pose any risk.
Because Smile CDR allows customer code to be added at deploy-time (via our interceptor mechanism) there is a chance that customer code may have chosen to use the log4j2 framework for logging. Customers are recommended to audit any code they have added to Smile CDR to ensure that it is not using log4j2.
Additional Technical Detail (Added 2021-12-13)
We have had a number of inquiries requesting additional detail about why the log4j library is included in our distribution. The following is a more detailed technical explanation of the results of our audit. Note that this explanation applies to both Smile CDR as well as the HAPI FHIR JPAServer Starter Project and any other project derived from the hapi-fhir-jpaserver-base module.
Smile CDR and HAPI FHIR use two complementary logging systems (SLF4J and Logback) for all of our system logging. These libraries are completely separate from log4j (the target of the CVE) and are not affected by this vulnerability.
We do include a part of the log4j library in our distribution, specifically a library called “log4j-api”. This library is included for compatibility with the database framework we use (Hibernate). Hibernate does use log4j, and we include a “bridge” that ensures Hibernate’s logs end up in the same files as the rest of the Smile CDR/HAPI FHIR logs.
Hibernate does not log any client-supplied messages, however, and logging specially crafted strings is the only way that CVE-2021-44228 can be exploited. Any user-supplied strings (e.g. FHIR resource contents, URL parameters, etc.) are always logged using SLF4j, meaning that even though log4j is present, it can not be exploited as it is only used to log fixed internal messages.
We will be updating the log4j library version in the next releases of Smile CDR and HAPI FHIR in order to avoid false-positive results from scanners, but at this time we do not believe there is any risk in using the current version of the products.
Update (Added 2022-01-07)
Since this original post was authored, several new vulnerabilities have been discovered in the Log4j library. These are numbered CVE-2021-44832, CVE-2021-45105, and CVE-2021-45046.
While these issues are not as severe as the original issue (CVE-2021-44228), they are still potentially serious and have generated a lot of concern.
It is important to stress that Smile CDR is not vulnerable to these issues either, for the same reason: We include a Log4j API library (log4j-api) in our distribution for compatibility reasons, but we do not include the Log4j Core library (log4j-core), and it is the latter library where these vulnerabilities are found.
Despite this, we have had requests from some customers to produce a build of Smile CDR that does not include the Log4j API library with a version number matching the vulnerable Log4j Core library. As a result, we have released Smile CDR 2021.11.R03. This new build is available immediately.
To be clear: There is no vulnerability in previous versions of Smile CDR, and there is no requirement to upgrade. However, if you have scanning tools that are producing false positives, it may be helpful to upgrade to avoid this.
As always, we are happy to discuss this if you have any further concerns and remain vigilant about any vulnerabilities discovered in our software and libraries.