Resolve and the log4j exploit?

I can see traces on the forum of Resolve using log4j to some extent. Have any one heard anything from BM if Resolve, or other BM products, are affected? They did a very cryptic tweet with little to no info about a security issue (https://twitter.com/Blackmagic_News/sta ... 4646439937) .

Maybe someone from BM can clarify?

I just did some brief research and so far as I can tell, Resolve shouldn't be vulnerable to the log4j exploit because Resolve uses log4cxx, and that does not suffer from the same vulnerability. The log4j exploit is in the JNDI receiver, which is unique to Java.

Here for example is a statement from the makers of Cerberus FTP, stating that their product - which uses log4cxx - isn't and couldn't be vulnerable: https://support.cerberusftp.com/hc/en-u ... nerability

"Cerberus is not and cannot be affected by CVE-2021-44228, log4j 0-day vulnerability. Cerberus FTP Server does not use the vulnerable Java log4j library, but a similar C++ rewrite called Log4cxx. The Log4cxx library is patterned after log4j, but the two libraries are fundamentally different and do not share any code."


Of course, no-one should take my word on this on matters of security - contact BMD directly if you're concerned, etc etc. Really BMD should put out their own statement, as Cerberus did.

No idea what the security vulnerability mentioned in the tweet might be. That's an incredibly useless tweet.

What I found using a log4j-scanner (https://github.com/hillu/local-log4j-vu ... r/releases):
c:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Libraries\Photon.jar (org/apache/log4j/net/SocketNode.class): log4j 1.2.17

This version should not be vulnerable.

I have a theory that whatever this mystery exploit is, it was in the Qt library.

We know that the Qt library was upgraded in version 17.4 (causing even more display scaling issues for Windows users). I just checked the versions installed in 17.3.2 versus 17.4, and found that:

- Fusion Studio and Resolve Studio 17.3.2 (and earlier) used Qt 5.4.1
- Fusion Studio and Resolve Studio 17.4+ use Qt 5.15.2

Checking the CVE database, there's a large number of Qt vulnerabilities that affect Qt versions prior to 5.15.2. I won't list them all because there's dozens, but here's a list: https://www.cvedetails.com/vulnerabilit ... 63/QT.html

The most severe exploits listed are CVE-2020-12267 which affects Qt versions prior to 5.14.2 and CVE-2018-19873 which affects Qt versions prior to 5.11.3.

So the tweet could be referring to any of those - or all of those.

Or it might be something else entirely, in some other library that got upgraded, or in Resolve itself. Who knows, when the information provided is so inadequate.

At least it's good to see that Resolve and Fusion Studio are finally using a supported version of Qt again (support for 5.4 ended in July 2017 - four years and three months before BMD stopped using it )

What I found using a log4j-scanner (https://github.com/hillu/local-log4j-vu ... r/releases):
c:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Libraries\Photon.jar (org/apache/log4j/net/SocketNode.class): log4j 1.2.17

This version should not be vulnerable.

Ah, good catch. So they do bundle log4j, but as part of a supplementary library. And this was not updated in 17.4 (hasn't been updated for many years it looks like.)

I am still pretty sure the mystery vulnerability tweet was Qt related.

Ah, good catch. So they do bundle log4j, but as part of a supplementary library. And this was not updated in 17.4 (hasn't been updated for many years it looks like.)

I am still pretty sure the mystery vulnerability tweet was Qt related.

maybe this one https://github.com/Netflix/photon

What Versions of Log4j are Affected?
All versions from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0
Has Apache Released a Fix for CVE-2021-45046?
Yes. In response to the issue, Apache Log4j 2.16.0 was released for Java 8 and up and 2.12.2 for Java 7.


Source of the information:
https://www.fortiguard.com/threat-signa ... of-service

Therefore this one was only referring the old log4shell not the new one
https://www.slashcam.com/news/single/Bl ... 16939.html

Blackmagic should give us some answers!

Unless you have your copy of resolve listening on the internet some how so people can send attacks to it you are not vulnerable to any thing. The Log4J issue is a big problem for things like apache servers because computers can attach to the listening web server and send it specially designed instructions. That is not how resolve is used.

maybe this one https://github.com/Netflix/photon

Yes you're right, it's that.

Unless you have your copy of resolve listening on the internet some how so people can send attacks to it you are not vulnerable to any thing. The Log4J issue is a big problem for things like apache servers because computers can attach to the listening web server and send it specially designed instructions. That is not how resolve is used.

Yeah. How would you exploit it remotely? There's no webserver allowing remote access to Resolve.

And even if it were somehow accessible remotely, Log4J 1.x is only affected by one of the Log4J vulnerabilities (CVE-2021-4104), which has the following details:

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default.

JMSAppender is not used in the Photon.jar config which, as it says, is not default log4j config, and regardless the exploit also requires write access to the log4j configuration.

Resolve is not affected by the Log4J exploit(s), for several different reasons.

What bug it WAS affected by - what that mystery tweet was about - is a different question. As I theorised before, they may well have been referring to the many Qt issues that got resolved when they upgraded from Qt 5.4.1 to 5.15.2.

But BMD are refusing to clarify, which is pretty bad.

Regarding the patch that BMD released, the third party that found the exploits in Resolve (Talos, part of Cisco) has posted about it. The issues were in the DPDecoder service that uses the R3D SDK to decode/debayer RED raw files. Not related to log4j.

Vulnerability Spotlight: Vulnerabilities in DaVinci Resolve video editing software could lead to code execution

TALOS-2021-1426 (CVE-2021-40417)
TALOS-2021-1427 (CVE-2021-40418)