-
Notifications
You must be signed in to change notification settings - Fork 290
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
RCE 0-day exploit in log4j #620
Comments
On HN someone suggested to use:
which we could suggest to use.
Did you try this out or is this in their documentation somewhere? |
apache/logging-log4j2#608 (comment) suggests one can also remove a class from the jar as "Holzhammer" solution. |
I'll see if it works to publish a jar without the class file. |
Removing the JndiLookup.class is now the officially recommended mitigation according to the Apache Log4j security page. To remove the class from your photon jar run:
Then restart your photon server. |
All jars downloadable from the Relase page for versions 0.3.x now have the JndiLookup.class removed. #621 makes sure that master builds remove the offending class when creating the final jar. I consider the issue thus closed for Photon. Please make sure to update your servers. |
See CVE-2021-44228 See https://logging.apache.org/log4j/2.x/security.html Unfortunately, upgrading to Log4J 2.15.0 is not possible because on uses an old version of ElasticSearch which relies on an old version of Log4J. See komoot/photon#620 for details.
Last night a 0-day exploit was published for log4j. This issue is to track impact for photon.
Current situation
We currently use log4j in version 2.8 and cannot update to a later version due to ES 5.6 not being compatible with those. This means that photon is affected and it is yet unclear if a patched version will be available.
A preliminary code analysis shows that the security risk for photon as a result of this exploit is low. Photon does not log any data received through requests via log4j itself. The only user-supplied data logged are filenames and data from the ES database in rare cases. However, photon does print exception messages and we cannot rule out that any of the libraries we use will print a message that is subject to the exploit.
Mitigation
The recommended mitigation for log4j 2.8 is to remove the JndiLookup.class from the final jar file. Ways to do this:
Always make sure to restart the server after you have deployed the updated photon jar.
The text was updated successfully, but these errors were encountered: