Log4j 1 is only affected if you have a "special" logging config with custom appenders that explicitely enable this feature. If anybody does this, heshe wants it.
Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Jason Gerlowski <[email protected]> > Sent: Friday, December 10, 2021 7:16 PM > To: [email protected] > Subject: Re: Log4J RCE vulnerability > > Does anyone know whether ZooKeeper is affected at all? I checked > their mailing list archive this morning to see if there was any > discussion of the issue, but didn't see anything either way. > > I would guess they're unaffected - the CVE seems specific to log4j2 > and ZK appears to still be on log4j-1.2.17. But I figured it was > worth checking here in case anyone knew more definitively. > > Jason > > On Fri, Dec 10, 2021 at 12:33 PM Uwe Schindler <[email protected]> wrote: > > > > 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: [email protected] > > > > > > > > From: Cassandra Targett <[email protected]> > > Sent: Friday, December 10, 2021 5:13 PM > > To: [email protected] > > 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 <[email protected]>, 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: [email protected] > > > > > > > > From: Gus Heck <[email protected]> > > Sent: Friday, December 10, 2021 1:32 PM > > To: [email protected] > > Subject: Re: Log4J RCE vulnerability > > > > > > > > In progress already it seems https://issues.apache.org/jira/browse/SOLR- > 15843 > > > > > > > > On Fri, Dec 10, 2021 at 7:29 AM Gus Heck <[email protected]> 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 <[email protected]> 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 > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: [email protected] > > > > > -----Original Message----- > > > From: Uwe Schindler <[email protected]> > > > Sent: Friday, December 10, 2021 11:10 AM > > > To: [email protected] > > > 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 > > > eMail: [email protected] > > > > > > > -----Original Message----- > > > > From: Uwe Schindler <[email protected]> > > > > Sent: Friday, December 10, 2021 10:35 AM > > > > To: [email protected] > > > > 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): 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://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 > > > > 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 > > > > eMail: [email protected] > > > > > > > > > -----Original Message----- > > > > > From: Bram Van Dam <[email protected]> > > > > > Sent: Friday, December 10, 2021 8:31 AM > > > > > To: [email protected] > > > > > 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/ > > > > > [2] https://news.ycombinator.com/item?id=29504755 > > > > > > > > > > > > > > > - Bram > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > > > -- > > > > http://www.needhamsoftware.com (work) > > > > http://www.the111shift.com (play) > > > > > > > > > > -- > > > > http://www.needhamsoftware.com (work) > > > > http://www.the111shift.com (play) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
