I like the idea of using our Wiki more as you describe. Not so much *new* news entries because I think search-ability of these CVEs is fine to an existing entry.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Sat, Dec 18, 2021 at 4:39 PM Gus Heck <gus.h...@gmail.com> wrote: > Thinking about it some more, maybe the problem with my suggestion is > the table on that page is organized by the library version and, if > unmitigated, the version of the library is still a problem. Maybe another > way to be clearer about it and avoid rewriting things that people have > already read would be to add independent entries to the security news page > for the newer CVE's > > On Sat, Dec 18, 2021 at 12:20 PM Gus Heck <gus.h...@gmail.com> wrote: > >> I think perhaps in the shock of such a deep and surprising vulnerability >> with such high visibility, we've begun to break with how we normally handle >> CVE's that don't apply to our usage of the library. Previously, they just >> got added to the list of known false positives >> <https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools>. >> Normally we wouldn't even mention them on the security news page, but >> because of the high visibility we should simply have a line mentioning that >> these two CVE's are on our false positives page and explain details there. >> The wiki would provide revision history automatically. >> >> On Sat, Dec 18, 2021 at 11:25 AM Jan Høydahl <jan....@cominvent.com> >> wrote: >> >>> We make edits to the log4j advisory almost daily, see >>> https://github.com/apache/solr-site/commits/e10a6a9fe0eed8dcba3ad1a076c8208e014e76ff/content/solr/security/2021-12-10-cve-2021-44228.md >>> I wonder if we should include a "Revision history" paragraph in the >>> advisory for transparency? >>> >>> Jan >>> >>> 15. des. 2021 kl. 19:09 skrev Uwe Schindler <u...@thetaphi.de>: >>> >>> Hi all, I prepared a PR about the followup CVE-2021-45046: >>> https://github.com/apache/solr-site/pull/59 >>> >>> Please verify and make suggestion. I will merge this into >>> main/production later. >>> >>> Uwe >>> >>> ----- >>> Uwe Schindler >>> Achterdiek 19, D-28357 Bremen >>> https://www.thetaphi.de >>> eMail: u...@thetaphi.de >>> >>> *From:* Uwe Schindler <u...@thetaphi.de> >>> *Sent:* Wednesday, December 15, 2021 3:31 PM >>> *To:* 'dev@lucene.apache.org' <dev@lucene.apache.org> >>> *Subject:* RE: Log4j < 2.15.0 may still be vulnerable even if >>> -Dlog4j2.formatMsgNoLookups=true is set >>> >>> 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> 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 >>> >: >>> >>> 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>: >>> >>> 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/fmr >>> >>> On 14 Dec 2021, at 23:44, Mike Drob <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> 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/fmr >>> >>> ------------------------------ >>> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> ------------------------------ >>> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: 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) >>> >>> >>> >> >> -- >> http://www.needhamsoftware.com (work) >> http://www.the111shift.com (play) >> > > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) >
