Log4j zero day remote code execution exploit

[WalkingMan]

Hello,
I didn't see anything confirming one way or another so wanted to ask. I know Subsonic relies on Log4j. Can anyone confirm if Subsonic is impacted by this exploit?
If it is any feedback on how to fix and secure?
thanks in advance!

(http://www.subsonic.org/pages/libraries.jsp)

https://www.veracode.com/blog/security-news/urgent-analysis-and-remediation-guidance-log4j-zero-day-rce-cve-2021-44228

[G8DHE]

The version of Subsonic I'm using uses the earlier version of LOG4j which isn't affected by the current exploits but has other problems.

[Phatteus]

Most companies that rely on log4j (and many that don't) are releasing statements regarding this vulnerability (https://nvd.nist.gov/vuln/detail/CVE-2021-44228)

I'd like to see Subsonic do the same. My version of Subsonic appears to use log4j 1.2.16

From NVD (highlight is mine, to indicate relevance with my version of Subsonic):

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true” or it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Is the proposed solution something we can do ourselves without breaking functionality in Subsonic?

[J_T_W]

See this thread: http://forum.subsonic.org/forum/viewtopic.php?f=5&t=18877

[Phatteus]

See this thread: http://forum.subsonic.org/forum/viewtopic.php?f=5&t=18877

This is very helpful, thank you!

[J_T_W]

Adding this to the chain:

https://www.reddit.com/r/airsonic/comments/rdycb3/is_airsonic_affected_by_log4j_0day_vulnerability/
https://github.com/airsonic-advanced/airsonic-advanced/issues/699

[WalkingMan]

See this thread: http://forum.subsonic.org/forum/viewtopic.php?f=5&t=18877

This is very helpful, thank you!

Agree! Thank you so much!

[jay_uk]

Most companies that rely on log4j (and many that don't) are releasing statements regarding this vulnerability (https://nvd.nist.gov/vuln/detail/CVE-2021-44228)

I'd like to see Subsonic do the same. My version of Subsonic appears to use log4j 1.2.16

From NVD (highlight is mine, to indicate relevance with my version of Subsonic):

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true” or it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Is the proposed solution something we can do ourselves without breaking functionality in Subsonic?

So without migrating to Airsonic, is there anything that we need/can do to fix the log4j exploit? My version also uses 1.2.16.

[G8DHE]

As I understand it the current CVE relates only to Log4j version 2 - https://nvd.nist.gov/vuln/detail/CVE-2021-44228
There have been other problems relating to Log4j version 1 which have been listed here - https://cve.mitre.org/cgi-bin/cvename.c ... 2019-17571

Perhaps the first thing we need to understand is which versions of Subsonic use log4j2 and which use Log4j1 ?
I've stuck with Subsonic V6.0 which only uses Log4j1 so appear to be unaffected by the current concerns although still open to the previous CVE-2019-17571
Perhaps others using different versions of Subsonic can confirm which release is used ?

[bushman4]

As I understand it the current CVE relates only to Log4j version 2 - https://nvd.nist.gov/vuln/detail/CVE-2021-44228
There have been other problems relating to Log4j version 1 which have been listed here - https://cve.mitre.org/cgi-bin/cvename.c ... 2019-17571

Perhaps the first thing we need to understand is which versions of Subsonic use log4j2 and which use Log4j1 ?
I've stuck with Subsonic V6.0 which only uses Log4j1 so appear to be unaffected by the current concerns although still open to the previous CVE-2019-17571
Perhaps others using different versions of Subsonic can confirm which release is used ?

The latest version, 6.1.6, uses Log4j1.

Glenn

[G8DHE]

In that case it seems to me from the write-ups that Subsonic will only be affected by the exploits dating from 2019 and not the latest problems - unless anyone knows better ?

[bushman4]

In that case it seems to me from the write-ups that Subsonic will only be affected by the exploits dating from 2019 and not the latest problems - unless anyone knows better ?

Correct. And the Log4j1 serialization vulnerability requires that the software have an open log4j.net.SocketServer and that that port is reachable by the attacker. In my install (running in a docker on Unraid), subsonic is listening on ports 4040 (the web interface) and also ports 9412, 38629, 34185, and 40973. I have no idea why it is listening on those other ports, but the only port I have forwarded into it from my border firewall is 4040, so even if one of those other ports are a log4j.net.SocketServer, the only people who would be able to hit it are on my internal network.

I am not concerned about that attack vector personally.

(NB: While network security is my profession, and Log4J2 has been my focus for the past 5 days, I do not have the code, so I am only reporting on what I can see from external diagnostic and forensic techniques)

Glenn