log4j vulnerability: afaict we're safe? about apollo

[hexylena]

More information from log4j, https://logging.apache.org/log4j/2.x/security.html two CVEs specifically we're safe from, and one that does apply in non standard configuration

Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: Audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.

[hexylena]

https://www.openwall.com/lists/oss-security/2021/12/13/1 does affect 1.2.X but it seems to only do so in unusual configurations

[cmdcolin]

this was essentially my assessment as well, that we sort of "dodged a bullet" on this log4j issue by using log4x 1.x which is only vulnerable in a non-default configuration. I ran apollo through a security scanner tool and found that we use the older log4j 1.x instead of 2.x which has the highest vulnerability scale

security scan here

https://gist.github.com/cmdcolin/df8e92fe3e82fb2856b5c08d90bf4a32

it would likely still be valuable to update dependencies

[hexylena]

Oh that's quite a list. yeah might be time. Thanks for the confirmation @cmdcolin !!

[garrettjstevens]

I looked a bit into what it would take to update dependencies to address some of the security concerns. Most of the dependencies are part of the Grails distribution, so the way to update the dependencies is to update Grails. Apollo is using Grails 2.5.5, and updating to more recent Grails version (current is 5.1.1) would be an extensive effort. For example, here is the migration guide from Grails 2 to 3: https://docs.grails.org/3.0.0/guide/single.html#upgrading

There seems to be some way of manually specifying dependencies described here, but it's not clear how exactly to generate that list, and it's all-or-nothing, you have to manually specify all the dependencies manually or none of them. Also, Grails 2 dependes on a lot of old versions of packages that might not be getting security updates anyway.

There is also a way to swap out the logging library specifically here, but since the versions of Log4j being used isn't as vulnerable, it's probably not as high a priority as some of the other dependencies.

[cmdcolin]

v2.7.0 released with updated log4j to safe version. it was likely in a non-vulnerable configuration by default anyways but the upgrade was requested by @childers

xref
#2654