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]
