Hi,
Log4j 2.15.0 defaults to this setting enabled. This was not the case since the 2nd release candidate this moring and the final log4j release. No log4j 2.15 had this system property removed, so it does nothing anymore. The problem with first fix was that there were still other ways to exploit this (not LDAP something else). So the decision by log4j team was to disable any expansions in logging messages. You need to enable them in your loggin patterns config file explicitly. Mike already released a statement in the security section on web page. We should send an information on mailing list, too. I am tweeting this, too. Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de From: Cassandra Targett <casstarg...@gmail.com> Sent: Friday, December 10, 2021 5:13 PM To: dev@solr.apache.org Subject: RE: Log4J RCE vulnerability Uwe, I understand Log4J 2.15.0 is going to address the vulnerability, but do you think we should add the system property 'log4j2.formatMsgNoLookups=true' anyway, just as a general good practice? I got that impression from reading your earlier message and wanted to confirm if I was correct. Even though we don’t need a CVE, I think we should proactively a) add a news item to the security.html page with the simple mitigation; and b) post the same to the solr-user list. I could tackle these if there are no objections. Cassandra On Dec 10, 2021, 7:44 AM -0600, Uwe Schindler <u...@thetaphi.de <mailto:u...@thetaphi.de> >, wrote: Hi, there was a message by the ASF security team to the members list: All projects should upgrade, but a CVE for each project is NOT needed: “Note: any updates of ASF projects needed to address this should reference CVE-2021-44228 and do not require a project-specific CVE.” Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de <mailto:u...@thetaphi.de> From: Gus Heck <gus.h...@gmail.com <mailto:gus.h...@gmail.com> > Sent: Friday, December 10, 2021 1:32 PM To: dev@solr.apache.org <mailto:dev@solr.apache.org> Subject: Re: Log4J RCE vulnerability In progress already it seems <https://issues.apache.org/jira/browse/SOLR-15843> https://issues.apache.org/jira/browse/SOLR-15843 On Fri, Dec 10, 2021 at 7:29 AM Gus Heck < <mailto:gus.h...@gmail.com> gus.h...@gmail.com> wrote: i think upgrade is a preferable solution lest we field repeated emails/jiras about vulnerability scanners detecting it. On Fri, Dec 10, 2021 at 6:24 AM Uwe Schindler < <mailto:u...@thetaphi.de> u...@thetaphi.de> wrote: With log4j 2.15.0 this should be fixed and by default all expansions on log messages were disabled: <https://issues.apache.org/jira/browse/LOG4J2-3198> https://issues.apache.org/jira/browse/LOG4J2-3198 ----- Uwe Schindler Achterdiek 19, D-28357 Bremen <https://www.thetaphi.de> https://www.thetaphi.de eMail: <mailto:u...@thetaphi.de> u...@thetaphi.de > -----Original Message----- > From: Uwe Schindler < <mailto:u...@thetaphi.de> u...@thetaphi.de> > Sent: Friday, December 10, 2021 11:10 AM > To: <mailto:dev@solr.apache.org> dev@solr.apache.org > Subject: RE: Log4J RCE vulnerability > > In general the sysprop "log4j2.formatMsgNoLookups=true" fix is the only > correct fix (maybe add it to the bootstrap class of solr). Updating log4j is > not > really needed. This prevents any of those shit. There's no reason ever to > parse > ${} escapes in log messages. The only place where this can be used is the > format pattern in the config file, but WTF was the idea behind that to pass > ALL > log messages through the expansion? > > Man man, SNEAKY log4j!!! 😊 > > Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > <https://www.thetaphi.de> https://www.thetaphi.de > eMail: <mailto:u...@thetaphi.de> u...@thetaphi.de > > > -----Original Message----- > > From: Uwe Schindler < <mailto:u...@thetaphi.de> u...@thetaphi.de> > > Sent: Friday, December 10, 2021 10:35 AM > > To: <mailto:dev@solr.apache.org> dev@solr.apache.org > > Subject: RE: Log4J RCE vulnerability > > > > Hi, > > > > I did some checks: > > - The problem also exists with logging parameters, so it is also executed > > if you > > call (which is IMHO a design failure in log4j, the reason for this is that > > the > > expansion is happending on printing the complete formatted log string to the > > output file): <http://logger.info> logger.info("Foobar: {}", > > "${badPayload}") > > - It also triggers if the message of an exception has a malicous payload! So > > happens easily if some input is validated and there's an > > IllegalArgumentException logged on validation errors > > > > To try out, and see it live do the following (can be done on any server, I > > tested > > it on my own servers, worked always): > > > > Start a local netcat: > > root@pangaea-mw1:~# nc -lp 1234 > > > > Go to any user interface of you application, e.g. solr or send a query > containing > > this payload, e.g. as part of a query string that is logged: > > ${jndi:ldap:// <http://127.0.0.1:1234/abc> 127.0.0.1:1234/abc} > > > > You will see cryptic text with emojis in the above netcat output. This shows > > that it definitely made an external request. > > > > We should fix this in 8.11 by doing the following: > > a) add "-Dlog4j2.formatMsgNoLookups=true" to Solr's start scripts (easy > > fix, I > > did the same on all my servers). Add this to the *main shell script*, not > > to the > > <http://solr.sh.in> solr.sh.in files, as those are modified by users. > > b) possibly update log4j, but with above fix it's not urgent and should not > > be > > done in 10.0. > > > > Uwe > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > <https://www.thetaphi.de> https://www.thetaphi.de > > eMail: <mailto:u...@thetaphi.de> u...@thetaphi.de > > > > > -----Original Message----- > > > From: Bram Van Dam < <mailto:bram.van...@intix.eu> bram.van...@intix.eu> > > > Sent: Friday, December 10, 2021 8:31 AM > > > To: <mailto:dev@solr.apache.org> dev@solr.apache.org > > > Subject: Log4J RCE vulnerability > > > > > > Heads up: > > > > > > Seems like there's a pretty severe remote code execution vulnerability > > > [1] in Log4J. Basically any application that uses log4j and that allows > > > user input to be injected into a logging string is susceptible. This > > > probably includes Solr. > > > > > > Further interesting discussion on Hacker News [2] > > > > > > [1] <https://www.lunasec.io/docs/blog/log4j-zero-day/> > > > https://www.lunasec.io/docs/blog/log4j-zero-day/ > > > [2] <https://news.ycombinator.com/item?id=29504755> > > > https://news.ycombinator.com/item?id=29504755 > > > > > > > > > - Bram > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: <mailto:dev-unsubscr...@solr.apache.org> > > > dev-unsubscr...@solr.apache.org > > > For additional commands, e-mail: <mailto:dev-h...@solr.apache.org> > > > dev-h...@solr.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: <mailto:dev-unsubscr...@solr.apache.org> > > dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: <mailto:dev-h...@solr.apache.org> > > dev-h...@solr.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: <mailto:dev-unsubscr...@solr.apache.org> > dev-unsubscr...@solr.apache.org > For additional commands, e-mail: <mailto:dev-h...@solr.apache.org> > dev-h...@solr.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: <mailto:dev-unsubscr...@solr.apache.org> dev-unsubscr...@solr.apache.org For additional commands, e-mail: <mailto:dev-h...@solr.apache.org> dev-h...@solr.apache.org -- <http://www.needhamsoftware.com> http://www.needhamsoftware.com (work) <http://www.the111shift.com> http://www.the111shift.com (play) -- <http://www.needhamsoftware.com> http://www.needhamsoftware.com (work) <http://www.the111shift.com> http://www.the111shift.com (play)
