Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

log4j vulnerability: afaict we're safe? #2640

Open
hexylena opened this issue Dec 15, 2021 · 6 comments
Open

log4j vulnerability: afaict we're safe? #2640

hexylena opened this issue Dec 15, 2021 · 6 comments

Comments

@hexylena
Copy link
Collaborator

Just wanted to open this for discussion since lots of us still deploy apollo and I haven't heard any word from maintainers, I've tested this morning using https://log4shell.tools/ and it doesn't get a response for either DNS or LDAP lookups. It seems we might be saved by using an ancient log4j! Fantastic

@hexylena
Copy link
Collaborator Author

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
Copy link
Collaborator

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
Copy link
Collaborator Author

hexylena commented Dec 15, 2021

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

@hexylena
Copy link
Collaborator Author

hexylena commented Dec 18, 2021

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.

@garrettjstevens
Copy link
Contributor

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
Copy link
Collaborator

cmdcolin commented Jan 4, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants