[et_pb_section fb_built=”1″ admin_label=”section” _builder_version=”3.22″ da_disable_devices=”off|off|off” global_colors_info=”{}” da_is_popup=”off” da_exit_intent=”off” da_has_close=”on” da_alt_close=”off” da_dark_close=”off” da_not_modal=”on” da_is_singular=”off” da_with_loader=”off” da_has_shadow=”on”][et_pb_row admin_label=”row” _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” global_colors_info=”{}” custom_padding__hover=”|||”][et_pb_text _builder_version=”4.14.5″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]
Log4j Lucidum 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.
Lucidum 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 Lucidum platform utilizes the Log4j framework in a backend service running in a Docker container. The Lucidum 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 Lucidum appliances typically not being exposed publically minimized the potential impact. All Lucidum customer appliances for which Lucidum had access were updated on Friday, December 10.
Lucidum’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 Lucidum UI, you can click on the System Setting page and hover over the System Setting tooltip. The back-end build hash below indicates Lucidum’s mvp1_backend container is V2.7.0 that includes the updated Log4J 2.15.0 package.
b016763c20c199c5e84bd6eaf39badc21b1b55fa
[/et_pb_text][et_pb_image src=”https://lucidum.io/wp-content/uploads/2022/01/image-20211214-215659-1.png” title_text=”image-20211214-215659-1″ _builder_version=”4.14.4″ _module_preset=”default” global_colors_info=”{}”][/et_pb_image][et_pb_image src=”https://lucidum.io/wp-content/uploads/2022/01/image-20211214-215649-1.png” title_text=”image-20211214-215649-1″ _builder_version=”4.14.4″ _module_preset=”default” global_colors_info=”{}”][/et_pb_image][et_pb_text _builder_version=”4.14.4″ _module_preset=”default” global_colors_info=”{}”]
If needed, additional verification from the CLI can be run. From the Lucidum CLI, check for the Docker container mvp1_backend version 2.7.0:
[ubuntu@lucidum:~$ 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@lucidum:~$ 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
/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.15.0.jar
/bitnami/tomcat/data/CMDB/WEB-INF/lib/log4j-api-2.15.0.jar
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 Lucidum customer appliances for which Lucidum had access were updated on Friday, December 10. An option is estimated to be available in Q1 2021 allowing easier upgrades to Lucidum platform components from the web UI. At this time platform component updates are initiated from the CLI.
In the case of Lucidum upgrading the mvp1_backend container to version 2.7.0, the following commands were run.
[cd /usr/lucidum
source venv/bin/activate
cd update-manager/
python update_manager.py ecr -c mvp1_backend:V2.7.0 -r
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]