The vulnerability is quite nasty. If there is a user string logged in a log4j line, then you are vulnerable. I would suspect everyone would need to at least worry about it or risk becoming a bitcoin harvester.
tim On Sat, Dec 11, 2021 at 2:19 PM Shawn Heisey <apa...@elyograg.org> wrote: > On 12/11/21 2:05 PM, Scott Derrick wrote: > > Trying to mitigate the zero day log4j exploit without upgrading my > > solr instance > > > > per > > > https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228 > > > > I made the following edits : > > (Linux/MacOS) Edit your |solr.in.sh| file to include: > > |SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true" > > On my 8.11.0 server, I replaced all the log4j jars in server/lib/ext > (which were the 2.14.1 version) with the 2.15.0 versions. Solr is still > working after restarting. My Solr install isn't reachable by anyone > outside of the machine itself, so I don't worry too much about > vulnerabilities. If somebody breaches the server, they will already be > able to see and affect far more than what's in my Solr index. > > Updating jars in this way is something that does not always work. > Sometimes a dependency update will require changes to Solr's source > code. This is one instance where no code changes were required. > > > I restarted solr but would like to verify my instance is running with > > the log4j2 setting. > > > > I can't figure out how to see what SOLR_OPTS it started with? > > > Open the admin UI and look at the dashboard. It will give you all the > commandline JVM args that Solr was started with. If you see the "-D" > option that you added, you're good. > > You might also be able to see with "ps auxww | grep solr" which I know > works on Linux. Other operating systems might need different args for ps. > > Thanks, > Shawn > > >
