The widely used Apache Log4j2 framework was recently revealed to have an exploitable vulnerability (CVE-2021-44228). Earlier today, a second vulnerability (CVE-2021-45046) was discovered and found that the patch to address CVE-2021-44228 was incomplete.
The Unefen platform utilizes the Apache Log4j framework in a backend service running in a Docker container. The Unefen web UI is running in the Docker container image named mvp1_backend without root access, so the impact of CVE-2021-45046 was isolated. This combined with Unefen appliances typically not being exposed publically minimized the potential impact. All Unefen customer appliances for which Unefen had access were updated on Wednesday, December 15.
Unefen’s platform services are provided in orchestrated Docker containers. At the moment, there isn’t an overall platform version. There are back-end and front-end containerized components that each have their own version. From the Unefen UI, you can click on the System Setting page and hover over the System Setting tooltip. The back-end build hash below indicates Unefen’s mvp1_backend container is V2.7.0 including the updated Log4J 2.16.0 package.
af5218981a1cd7c217618b23d4677343e656f22a
If needed, additional verification from the CLI can be run. From the Unefen CLI, check for the Docker container mvp1_backend version 2.7.0.
$ docker ps |grep mvp1_backend
071797d46e10 mvp1_backend:V2.7.0 “/opt/bitnami/script…”
Check Log4j versions in the mvp1_backend Docker container:
$ docker exec -it $(docker ps -q –filter ancestor=mvp1_backend:V2.7.0) sh -c “find /|grep log4j”
find: ‘/root’: Permission denied
find: ‘/proc/tty/driver’: Permission denied
find: ‘/etc/ssl/private’: Permission denied
find: ‘/var/cache/ldconfig’: Permission denied
/bitnami/tomcat/data/CMDB/WEB-INF/lib/log4j-over-slf4j-1.7.30.jar
/bitnami/tomcat/data/CMDB/WEB-INF/lib/log4j-to-slf4j-2.16.0.jar
/bitnami/tomcat/data/CMDB/WEB-INF/lib/log4j-api-2.16.0.jar
In the output above, both log4j-to-slf4j and log4j-api are version 2.16.0. While log4j-over-slf4j is on version 1.7.30, this is not any cause for concern. This article discusses CVE-2021-44228 and is also applicable to CVE-2021-45046.
According to Simple Logging Facade for Java (SLF4J):
As log4j 1.x does NOT offer a JNDI look-up mechanism at the message level, it does NOT suffer from CVE-2021-44228.
The SLF4J API is just an API which lets message data go through. As such, using Log4j 2.x, even via SLF4J does not mitigate the vulnerability.
However, as mentioned already, Log4j 1.x is safe with respect to CVE-2021-44228. Thus, if your SLF4J provider/binding is slf4j-logj12.jar, you are safe regarding CVE-2021-44228.
If you are using log4j-over-slf4j.jar in conjunction with the SLF4J API, you are safe unless the underlying implementation is log4j 2.x.
While the article above does not state it explicitly, if the underlying implementation is Log4j 2.16.0 CVE-2021-45046 and CVE-2021-44228 are mitigated.
As previously mentioned, all Unefen customer appliances for which Unefen had access were updated on Wednesday, December 15. An option is estimated to be available in Q1 2021 allowing easier upgrades to Unefen platform components from the web UI. At this time platform component updates are initiated from the CLI.
In the case of Unefen upgrading the mvp1_backend container to version 2.7.0, the following commands were run.
cd /usr/unefen
source venv/bin/activate
cd update-manager/
python update_manager.py ecr -c mvp1_backend:V2.7.0 -r