Addressing the Log4j Vulnerability in Unifi Video 3.10.13
If you’ve been on the Internet at all today, you’ve probably heard that there is
a pretty nasty RCE issue with log4j, a logging package for Java applications.
The CVE is CVE-2021-44228,
and is a pretty scary RCE bug that is already being exploited in the wild.
Update: I originally had comments in this post stating Ubiquiti should update the NVR software. I’ve since learned it’s officially deprecated and won’t be receiving any updates.
Update 2: Method 1 highlighted below was found to not actually mitigate the threat, as the version of log4j included doesn’t support the flag. I’ve been running Method 2 for some time and have had no issues. I recommend doing that.
Update 3: As far as I know this does not address the subsequent DoS vulnerability (CVE-2021-45105).
The Unifi Controller is already confirmed to use the afflicted version, and a new release has already been patched.
Since the Unifi Video NVR product is not supported anymore (they’ve shifted focus onto the dedicated hardware products and Unifi Protect), there is no update in the works for this older software. If you’re like me and still have one of these installs around, you’re probably wondering if it’s affected and how to fix it.
Yes, 3.10.13 contains an un-patched log4j version that is affected by the CVE. If you have a Unifi Video server and it’s exposed to the Internet, you’ll likely want to patch your system.
Method 1: Disable Lookups
This does not mitigate the threat (see update 2 above). It’s included just for historical reasons
This method sets a soft flag that prevents log4j from doing the external
lookups that cause so many issues. There’s a community
post
that highlights the same workaround, and credit is due to them for sharing the
solution as well.
To patch things, edit /usr/sbin/unifi-video and find the JVM_OPTS section.
This is around line 231 in the file. Searching for either JVM_OPTS or
JVM_EXTRA_OPTS should get you pretty close.
Add this line before the JVM_OPTS line:
JVM_EXTRA_OPTS="-Dlog4j2.formatMsgNoLookups=true ${JVM_EXTRA_OPTS}"
Save that file and restart Unifi Video:
service unifi-video restart
What This Edit Does
/usr/sbin/unifi-video is a pretty long wrapper script for starting the Java
process, MongoDB process, and some other processes to make Unifi Video work. We
add the log4j2.formatMsgNoLookups=true option to JVM when it starts the Unifi
Video JAR, which effectively mitigates the vulnerability.
Method 2: Remove the JndiLookup Class
This protects against both CVE-2021-44228 and CVE-2021-44228.
This is a bit more of a complex solution, but removes the vulnerable code from the application entirely. I’ve run this setup on my local instal without issue for some time now, so I’m confident in its stability.
This method is taken from VeraCode, and seems to work just fine on Unifi Video.
First, let’s take a backup of the jar we’re going to modify:
cd /usr/lib/unifi-video/lib
cp log4j-core-2.1.jar /root/log4j-core-2.1.jar.bak
Next, let’s remove the JndiLookup class from the log4j-core package:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Restart Unifi Video as normal:
service unifi-video restart
What This Does
This patches the JAR file used by Unifi Video itself to not include the lookup
class at all. This class, as far as I am aware, is the source of the vulnerable
code. This removes the class entirely from the log4j library.