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

RCE 0-day exploit in log4j #620

Closed
lonvia opened this issue Dec 10, 2021 · 5 comments
Closed

RCE 0-day exploit in log4j #620

lonvia opened this issue Dec 10, 2021 · 5 comments

Comments

@lonvia
Copy link
Collaborator

lonvia commented Dec 10, 2021

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:

  1. 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
    
  2. (Photon >= 0.3.0 only) Download the photon jar from the release page again. The jars have been updated accordingly.
  3. (master only) Update to latest master and recompile photon (see Remove JndiLookup class from shaded jar #621).

Always make sure to restart the server after you have deployed the updated photon jar.

@lonvia lonvia pinned this issue Dec 10, 2021
@karussell
Copy link
Collaborator

On HN someone suggested to use:

log4j.formatMsgNoLookups=true or log4j2.formatMsgNoLookups=true

which we could suggest to use.

cannot update to a later version due to ES 5.6 not being compatible with those

Did you try this out or is this in their documentation somewhere?

@kannes
Copy link
Contributor

kannes commented Dec 10, 2021

apache/logging-log4j2#608 (comment) suggests one can also remove a class from the jar as "Holzhammer" solution.

@lonvia
Copy link
Collaborator Author

lonvia commented Dec 11, 2021

Did you try this out or is this in their documentation somewhere?

#477 (comment)

I'll see if it works to publish a jar without the class file.

@lonvia
Copy link
Collaborator Author

lonvia commented Dec 13, 2021

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:

zip -q -d photon-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Then restart your photon server.

@lonvia
Copy link
Collaborator Author

lonvia commented Dec 13, 2021

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.

@lonvia lonvia closed this as completed Dec 13, 2021
mlechner pushed a commit to OpenBfS/osm-stack that referenced this issue Apr 11, 2023
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.
@lonvia lonvia unpinned this issue Aug 22, 2023
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