Red5 Marked “Safe” from Log4j Zero-Day

SHARE

(Updated: 12/16/2021) The zero-day gremlins are at it again, this time with a nasty Log4j/Log4j2 vulnerability that’s been dubbed Log4Shell (CVE-2021-44228). First things first: Red5 offerings, including both the open source and the Red5 Pro closed source extensions, are not vulnerable as we do not use the affected libraries. Log4Shell allows a specially-crafted log message… Continue reading Red5 Marked “Safe” from Log4j Zero-Day

(Updated: 12/16/2021)

The zero-day gremlins are at it again, this time with a nasty Log4j/Log4j2 vulnerability that’s been dubbed Log4Shell (CVE-2021-44228). First things first: Red5 offerings, including both the open source and the Red5 Pro closed source extensions, are not vulnerable as we do not use the affected libraries.

Log4Shell allows a specially-crafted log message to reach out via LDAP to a compromised LDAP server, retrieving a payload that then executes on the recipient server. Unfortunately, this zero-day required very little work to exploit; proof of concept code was released almost immediately and there are already scans hitting servers across the globe probing for this vulnerability.

Log4j(2) is one of the most popular logging frameworks for Java and it is used extensively in Apache products such as Struts. It can also be found in popular games like Minecraft, which has many versions affected by this vulnerability. Literally thousands of projects include this library and use the affected versions; even tech giants like Apple’s iPhone and Tesla cars are not left unscathed. By no means is this going to be an issue that dies quietly.

Red5 stopped using Log4j over a decade ago. Instead, we opted to provide a shim that exposes the same interfaces as Log4j, but does not use any of its code. This approach allows us to continue to support our customers’ applications that expect this logging interface without using the affected libraries.

For those trying to mitigate the issue, it is possible that dropping in the replacement jar from this logging package will remove the vulnerability. Take a look at the Simple Logging Facade for Java for information on how legacy logging is supported without the Log4j code.

UPDATE (12/16/2021): Red5 uses Logback which has a lower severity vulnerability (as of the release of this update, the description at Mitre has yet to be filled).  To exploit this issue you need to have privileges to modify the Red5 Logback configuration telling Logback to make a JNDI connection.  If an attacker has access to modify the Red5 configuration files, this exploit is moot as the attacker already has control of the system configuration.  Out of caution, we are updating Logback in a release coming early next year and we will provide information on which configuration files should be added to your file change monitoring.

As with all zero-day attacks, it is important to keep an eye on this as more developments, more information about which versions are affected, and additional information about mitigation steps are being rapidly disseminated. The following resources are useful in keeping up with this issue:

CVE Information from Mitre

Exploit details and updated findings from Lunasec

GitHub PR addressing the issue in Log4j2

Apache information about the vulnerability

Nitties from Hackers

Log4j Zero-Day Impacts

Responses from Projects