RCE 0-day exploit in log4j
See original GitHub issueLast 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:
- Remove the class from your deployed photon-*.jar file using the zip tool:
zip -q -d photon-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- (Photon >= 0.3.0 only) Download the photon jar from the release page again. The jars have been updated accordingly.
- (master only) Update to latest master and recompile photon (see #621).
Always make sure to restart the server after you have deployed the updated photon jar.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:5 (1 by maintainers)
Top GitHub Comments
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.