CVE-2021-44228

[devicenull]

https://twitter.com/nluedtke1/status/1469435658389561345

It appears some configurations of log4j 1.x are vulnerable - is cyberduck using one of them?

[brunom]

CD seems to be using a really old version (1.2.17)

cyberduck/pom.xml

Line 198 in e4c2dfe

<version>1.2.17</version>

that has other security issues https://www.cvedetails.com/cve/CVE-2019-17571/

[dkocher]

As said we do not have a dependency for Apache Log4j 2. Also as a client side desktop application it does not seem relevant.

[brunom]

@dkocher Where was this discussed before? I searched but didn't find.
CD depends on log4J 1, not 2, but 1 seems to also be affected https://twitter.com/nluedtke1/status/1469435658389561345
Even as a client side app, maybe you connect to a server that has files with $ escapes that you log and run.

[devicenull]

@dkocher log4j shows up in your pom.xml - so something appears to be using it?

I also see a config file for it - https://github.com/iterate-ch/cyberduck/blob/fa0aa0d5d7b07ec09a4c328b2c0cf9a56bf01c4d/core/src/main/resources/log4j.xml

As well as references to it in your code-

cyberduck/core/src/main/java/ch/cyberduck/core/logging/LoggerPrintStream.java

Line 19 in 745598c

import org.apache.log4j.Level;

[dkocher]

It makes sense to eventually move away/upgrade from Log4j 1.x but I see no immediate urgency in this dependency upgrade. I do not see that CVE-2019-17571 would affect us as from my understanding this usage would need to be explicitly configured.

[jpilgrim]

CVE-2019-17571 is related to log4j versions >= 1.2, <= 1.2.27. In the Cyberduck package, I find log4j-1.2.17. Why does that not affect Cyberduck, even though the version of log4j is affected?

[AliveDevil]

Because that vulnerability only affects the log4j SocketServer which, when used to centrally log from remote clients, can execute arbitrary code. Cyberduck isn’t providing a central logging target so isn’t affected.

when listening to untrusted network traffic for log data

[brunom]

Since log4j 1 is out of support, vulnerabilities aren't tracked and we have to assume that it's unsafe.

[dkocher]

Since log4j 1 is out of support, vulnerabilities aren't tracked and we have to assume that it's unsafe.

Log4j 1.x does not feature the JNDI functionality that caused CVE-2021-44228

[brunom]

But it may have other undocumented issues.

[dkocher]

But it may have other undocumented issues.

Like any software.

[brunom]

log4j maintainers only document and fix issues on supported versions. Using log4j 1 is like using Windows XP: you don't even know the ways you could get attacked.

[boshuis]

There are already quite a number of (large) companies that do not allow any old (vulnerable) log4j libraries on employees laptops. Without a proper version of log4j, cyberduck is not working anymore since the library is automatically removed from company devices.

[dkocher]

There are already quite a number of (large) companies that do not allow any old (vulnerable) log4j libraries on employees laptops. Without a proper version of log4j, cyberduck is not working anymore since the library is automatically removed from company devices.

I have opened #12706.