We should add this to the webpage. Another one asked on the security mailing list.
Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de From: Gus Heck <gus.h...@gmail.com> Sent: Wednesday, December 15, 2021 12:39 AM To: dev <dev@lucene.apache.org> Subject: Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set Perhaps we could tweak it to say that the system property fix is sufficient *for Solr* (i.e. not imply that it is a valid work around for all cases) On Tue, Dec 14, 2021 at 6:20 PM Uwe Schindler <u...@thetaphi.de <mailto:u...@thetaphi.de> > wrote: The other attack vectors are also not possible with Solr: - Logger.printf("%s", userInput) is not used - custom message factory is not used Uwe Am 14. Dezember 2021 22:59:26 UTC schrieb Uwe Schindler <u...@thetaphi.de <mailto:u...@thetaphi.de> >: It is still a valid mitigation. Mike Drobban I explained it. MDC is the other attack vector and that's not an issue with Solr. Please accept this, just because the documentation of log4j changes, there's no additional risk. We may update the mitigation to mention that in Solr's case the system property is fine. Uwe Am 14. Dezember 2021 22:52:29 UTC schrieb solr <fred...@rodland.no <mailto:fred...@rodland.no> >: Ok. But FTR - apache/log4j has discredited just setting the system property as a mitigation measure, so I still think the SOLR security-page should be changed to not list this as a valid mitigation: https://logging.apache.org/log4j/2.x/security.html "Older (discredited) mitigation measures This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open. Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1. “ Regards, Fredrik -- Fredrik Rødland Cell: +47 99 21 98 17 Maisen Pedersens vei 1 Twitter: @fredrikr NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/ http://rodland.no about.me <http://about.me> http://about.me/fmr On 14 Dec 2021, at 23:44, Mike Drob <md...@mdrob.com <mailto:md...@mdrob.com> > wrote: The MDC Patterns used by solr are for the collection, shard, replica, core and node names, and a potential trace id. All of those are restricted to alphanumeric, no special characters like $ or { needed for the injection. And trying to access a collection that didn’t exist Returns 404 without logging. Upgrading is always going to be more complete, but I think we’re still ok for now, at least until the next iteration of this attack surfaces. On Tue, Dec 14, 2021 at 3:37 PM solr <fred...@rodland.no <mailto:fred...@rodland.no> > wrote: Only setting -Dlog4j2.formatMsgNoLookups=true might not be enough to mitigate the log4j vulnerability. See https://github.com/kmindi/log4shell-vulnerable-app “So even with LOG4J_FORMAT_MSG_NO_LOOKUPS true version 2.14.1 of log4j is vulnerable when using ThreadContextMap in PatternLayout.” ThreadContext.put(key, value) is used under the hood by MDC. I’m not sure wether any user-input is actually stored in MDC in SOLR. Probably this should be updated: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228 And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0? Regards, Fredrik -- Fredrik Rødland Cell: +47 99 21 98 17 Maisen Pedersens vei 1 Twitter: @fredrikr NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/ http://rodland.no about.me <http://about.me> http://about.me/fmr _____ To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org <mailto:dev-unsubscr...@lucene.apache.org> For additional commands, e-mail: dev-h...@lucene.apache.org <mailto:dev-h...@lucene.apache.org> _____ To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org <mailto:dev-unsubscr...@lucene.apache.org> For additional commands, e-mail: dev-h...@lucene.apache.org <mailto:dev-h...@lucene.apache.org> -- Uwe Schindler Achterdiek 19, 28357 Bremen https://www.thetaphi.de -- Uwe Schindler Achterdiek 19, 28357 Bremen https://www.thetaphi.de -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
