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)
