I'd expect the parsing to be mostly a no-op as the lookup no longer exists. Neutralized versions of the class could return an empty string which might remove the string, but it would otherwise be left intact and uninterpreted without the plugin available.
On Thu, Dec 16, 2021 at 7:08 PM Shawn Heisey <apa...@elyograg.org> wrote: > > One of the possible mitigations for the recent vulnerabilities is > removing the JndiLookup.class file from the log4j-core jar. > > One thing I am wondering is what happens if that step is taken and > somebody manages to cause an application to send the exploit text to the > log? Down in the bowels of log4j code, I think a ClassNotFoundException > will be thrown ... what does that exception mean for log4j as a whole? > Is it handled gracefully? > > I'm with the Solr project. Solr switched to log4j2 in the 7.4.0 > version, and at that time, it was 2.11.0 that was included. My hope is > that the API has remained stable enough from 2.11.0 through 2.16.0 that > simply replacing the log4j jars is a safe operation. We have had users > claim success when doing that replacement on their Solr installs, as far > back as log4j 2.13.0. > > Any information you can provide is appreciated. > > Thanks, > Shawn > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
