Log4j Unefen Appliance Update
A zero-day exploit for a vulnerability (CVE-2021-44228) in the widely-used Apache Log4j framework was publicly released on December 9th, 2021. This vulnerability allows for unauthenticated Remote Code Execution (RCE) by logging a certain string, making the Log4j library susceptible to exploitation A detailed description of the vulnerability can be found on the Apache Log4j Security Vulnerabilities page.
Unefen became aware of the Log4j vulnerability on December 10th, 2021, and immediately conducted an assessment across our codebase, then created, tested, and deployed a patch to all customers within twelve hours mitigating the impact.
The Unefen platform utilizes the 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-44228 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 Friday, December 10.
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 that includes the updated Log4J 2.15.0 package.
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:
[ubuntu@unefen:~$ docker ps |grep mvp1_backend
1e16fba7773a mvp1_backend:V2.7.0 “/opt/bitnami/script…” 3 days ago Up 3 days 0.0.0.0:80->8080/tcp, 0.0.0.0:443->8443/tcp
Check Log4j versions in the mvp1_backend Docker container:
[ubuntu@unefen:~$ docker exec -it $(docker ps -q –filter ancestor=mvp1_backend:V2.7.0) sh -c “find /|grep log4j”
find: ‘/proc/tty/driver’: Permission denied
find: ‘/etc/ssl/private’: Permission denied
find: ‘/var/cache/ldconfig’: Permission denied
find: ‘/root’: Permission denied
In the output above, both log4j-to-slf4j and log4j-api are version 2.15.0. While log4j-over-slf4j is on version 1.7.30, this is not any cause for concern.
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.15.0 CVE-2021-44228 is mitigated.
As previously mentioned, all Unefen customer appliances for which Unefen had access were updated on Friday, December 10. 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.
python update_manager.py ecr -c mvp1_backend:V2.7.0 -r