(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:
Exploit details and updated findings from Lunasec
GitHub PR addressing the issue in Log4j2
Apache information about the vulnerability
The Red5 Team brings together software, DevOps, and quality assurance engineers, project managers, support experts, sales managers, and marketers with deep experience in live video, audio, and data streaming. Since 2005, the team has built solutions used by startups, global enterprises, and developers worldwide to power interactive real-time experiences. Beyond core streaming technology, the Red5 Team shares insights on industry trends, best practices, and product updates to help organizations innovate and scale with confidence.
