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> 
https://issues.apache.org/jira/browse/SOLR-15843

 

On Fri, Dec 10, 2021 at 7:29 AM Gus Heck < <mailto:[email protected]> 
[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 < <mailto:[email protected]> 
[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> 
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:[email protected]> [email protected]

> -----Original Message-----
> From: Uwe Schindler < <mailto:[email protected]> [email protected]>
> Sent: Friday, December 10, 2021 11:10 AM
> To:  <mailto:[email protected]> [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> https://www.thetaphi.de
> eMail:  <mailto:[email protected]> [email protected]
> 
> > -----Original Message-----
> > From: Uwe Schindler < <mailto:[email protected]> [email protected]>
> > Sent: Friday, December 10, 2021 10:35 AM
> > To:  <mailto:[email protected]> [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):  <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:[email protected]> [email protected]
> >
> > > -----Original Message-----
> > > From: Bram Van Dam < <mailto:[email protected]> [email protected]>
> > > Sent: Friday, December 10, 2021 8:31 AM
> > > To:  <mailto:[email protected]> [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/> 
> > > 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:[email protected]> 
> > > [email protected]
> > > For additional commands, e-mail:  <mailto:[email protected]> 
> > > [email protected]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:  <mailto:[email protected]> 
> > [email protected]
> > For additional commands, e-mail:  <mailto:[email protected]> 
> > [email protected]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:  <mailto:[email protected]> 
> [email protected]
> For additional commands, e-mail:  <mailto:[email protected]> 
> [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail:  <mailto:[email protected]> 
[email protected]
For additional commands, e-mail:  <mailto:[email protected]> 
[email protected]




 

-- 

 <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)

Reply via email to