I’ve been scratching my head with a few of our custom modules that we have developed since migration to 4.8.17+1. Specifically right now, our custom logging module is not working. It creates a JSON file we use for logging purposes and extraction into another system. My question, has the base implementation of calling log4J changed? Sounds like a stupid question I know. I WAS using this example (Create Custom Log and Write to it from Custom Module) and it was working wonderful. But in upgrading, it does not love me anymore. Can someone provide some insight? I 100% could be doing something silly in the implementation, but I have a version of it running in production that leverages the much older version of Log4J. Thanks in advance!
Hey @Rich_Sokol thanks for reaching out. So the log4j/CVE issues were a biggie in December around the world as you already know and we posted about in forums, in docs and in an email. Here is the most recent info:
Apache Log4j2 security vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105)
Logging in Wowza Streaming Engine 4.8.8.01 and later uses a version of Apache Log4j2 with a security vulnerability (CVE-2021-44228) involving JNDI functionality that is not protected against attacker-controlled LDAP and other JNDI-related endpoints.
In addition, steps to mitigate CVE-2021-44228 in Apache Log4j 2.15.0 and 2.16.0 did not fully address security vulnerabilities. These issues are captured in CVE-2021-45046 and CVE-2021-45105.
We recommend Wowza Streaming Engine customers take action to address the recent Apache Log4j2 vulnerabilities by using our Log4j2 updater to get the latest Log4j2 files: see Update to fix Apache Log4j2 security vulnerabilities to get the updater and for information about runnning it.
Although Wowza Streaming Engine 4.8.17 upgrades to Apache Log4j 2.16.0 to fix CVE-2021-44228 and CVE-2021-45046, it does not fix CVE-2021-45105, which is fixed in Apache Log4j 2.17.0.
Important: You do not need to update to Wowza Streaming Engine 4.8.17 to get the latest fixes for Apache Log4j2-related issues.
Addressing recent Apache Log4j2 issues is a dynamic situation that we will continue to respond to based on Apache updates.
Did you already address these changes and are you using the correct version on Apache log4j2? If yes and you mentioned some custom modules, you’ll need to send a support ticket. It’s possible we these critical upgrades that came from Apache, things broke and we’ll need to see where and why.
If you’re on a fresh install of 4.8.17+1 or you upgraded and addressed the suggested fixes AND you can confirm you have Logfj-version 2.17.0, then you don’t need to update anything else.
But it sounds like we should review those custom modules, files and logs in a ticket. I don’t believe anything changed as far as calling lof4j, just the libraries.
Do you have log4j debugging enabled?
Thanks @Rose_Power-Wowza_Com. I THINK we have stumbled onto the issue, but we are still not 100% sure how to resolve it. We develop our modules on a Windows server w/ eclipse. On this server we have the WSE library (WowzaLibrary\WSE\java\lib) to build our modules which needs to match the WSE Server (installPath/Wowza/lib/). That was a question by the way? We’ve upgraded WSE to 4.8.17+1 (including log4j updater to 2.17.1), but have not TOUCHED the library on our Windows server where we build the modules. So… the dev server still has log4j-1.2.17, and our custom module specifically uses log4j. When we compile and deploy to our to-be-prod WSE it is using 2.17.1. It seems we need to update the module library to use 2.17.1 api & core on the dev server, then figure out how to make the reference in the module, and then update the correct java code to implement the new jar files. Do you all have any updated code for the log4j module example you originally provide to the community? And… does that sound correct?