-
Notifications
You must be signed in to change notification settings - Fork 85
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
Comments
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 |
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 |
Oh that's quite a list. yeah might be time. Thanks for the confirmation @cmdcolin !! |
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
|
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. |
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
The text was updated successfully, but these errors were encountered: