log4j2 in UCS
tl;dr: UCS in itself is not vulnerable, but Java based apps may be. We currently scan apps and update this posting as we find out more. To make things more transparent Univention will publish a list of all apps to help continuous triage of their status. Currently we have no indication of critically exploitable apps yet. We’ll keep you posted.
While UCS 5.0-0 ships apache-log4j2 as a Debian package, it’s not used anywhere by default. As apache-log4j2 is a package that has unmaintained status in UCS, the package update is not visible on our regular errata tracking page. Updates to apache-log4j2 version 2.15.0-1~deb10u1 (CVE-2021-44228) have been made available for customers on 2021-12-13, an update to apache-log4j2 version 2.16.0-1~deb10u1 (CVE-2021-45046) has been made available on 2021-12-16.
There is also CVE-2021-44832, which has a significantly smaller chance of getting exploited. We will ship an update once Debian updated the package.
UCS 4.4 is not affected by CVE-2021-45046, as the JndiLookup class has been removed from the package in package version 2.7-2+deb9u1, which was the fix for CVE-2021-44228.
UCS
UCS 5.0 errata5.0-0 + errata5.0-1
$ apt-cache policy liblog4j2-java
2.16.0-1~deb10u1 500
500 http://updates.software-univention.de errata501/main amd64 Packages
500 http://updates.software-univention.de errata500/main amd64 Packages
2.15.0-1~deb10u1 500
500 http://updates.software-univention.de ucs501/main amd64 Packages
UCS 4.4 errata4.4-8
$ apt-cache policy liblog4j2-java
2.7-2+deb9u1 500
500 http://updates.software-univention.de/4.4/unmaintained/component 4.4-8-errata/all/ Packages
Additional information is available in the upstream package status for CVE-2021-44228 and the upstream package status for CVE-2021-45046.
The UCS-4 package apache-log4j1.2 is not affected by CVE-2021-44228 but by the related vulnerability CVE-2021-4104, which doesn’t allow remote code execution (RCE) though, as far as currently known. By default it’s also not used in UCS and it’s actually in the unmaintained branch of the UCS repositories. We are currently waiting for an upstream update though.
log4j2 in apps installable on the UCS plattform
There are some Java based apps, that potentially could be affected, here is the status:
- Zammad uses elaticsearch and issued a Zammad security advisory
- Seafile issued a security advisory. It uses elasticsearch, which also issued an advisory, and is not affected by RCE but may be susceptible for information leak e.g. of environment variables in the docker container.
-
Jitsi issued a security advisory. It is only affected when
callstatsare enabled. - Guacamole: no
- Itiseasybusiness: no
- Bluespice: Elastic Meldung/Log4Shell – BlueSpice Wiki
- Wordpress: no
- Etherpad-lite: no
- Odoo: no
- Let’s encrypt: no
- Jenkins: Apache Log4j 2 vulnerability CVE-2021-44228
- Synapse: no
Our tests with the elasticsearch based apps showed that they are not vulnerable to RCE because elaticsearch uses Java Security Manager. Yet, it may leak information like environment variables. The scope of this depends on the type of app that uses elasticsearch. If it is a docker based app, then the environment is the one inside the docker container.
log4j2 in UCS apps
- Kelvin: OpenAPI-generator uses swagger which uses log4j. Our assessment is that it would be very hard to exploit this, if possible at all. It would at least require injecting crafted python modules as UDM extensions, which requires Administrator privilege. So, it’s safe to assume that it’s not exploitable remotely.
- Veyon Proxy: no
- Apple-School-Manager: no
- Ox-Connector: no
log4j2 in other components
Please also note that UCS offers connectors to several third party solutions, which may be vulnerable. While this doesn’t expose UCS directly, it may open options for post exploitation techniques and lateral movement.
There are large collections of general overviews about log4j related advisories like that may be helpful to gain a general overview about other software components, most of them unrelated to UCS.