You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Uwe Schindler <uw...@thetaphi.de> on 2021/12/10 09:35:21 UTC
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: uwe@thetaphi.de
> -----Original Message-----
> From: Bram Van Dam <br...@intix.eu>
> Sent: Friday, December 10, 2021 8:31 AM
> To: 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/
> [2] https://news.ycombinator.com/item?id=29504755
>
>
> - Bram
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Log4J RCE vulnerability
Posted by Mike Drob <md...@mdrob.com>.
I’ve already posted an item to our security page. If you have improvements,
please add them, my copy was certainly rushed.
Informing our user list is a good idea too!
On Fri, Dec 10, 2021 at 10:13 AM Cassandra Targett <ca...@gmail.com>
wrote:
> 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 <uw...@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.google.com/maps/search/Achterdiek+19,+D-28357+Bremen?entry=gmail&source=g>
>
> https://www.thetaphi.de
>
> eMail: uwe@thetaphi.de
>
>
>
> *From:* Gus Heck <gu...@gmail.com>
> *Sent:* Friday, December 10, 2021 1:32 PM
> *To:* dev@solr.apache.org
> *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 <gu...@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 <uw...@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
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> <https://www.google.com/maps/search/Achterdiek+19,+D-28357+Bremen?entry=gmail&source=g>
> https://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Uwe Schindler <uw...@thetaphi.de>
> > Sent: Friday, December 10, 2021 11:10 AM
> > To: 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.google.com/maps/search/Achterdiek+19,+D-28357+Bremen?entry=gmail&source=g>
> > https://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> > > -----Original Message-----
> > > From: Uwe Schindler <uw...@thetaphi.de>
> > > Sent: Friday, December 10, 2021 10:35 AM
> > > To: 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): 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.google.com/maps/search/Achterdiek+19,+D-28357+Bremen?entry=gmail&source=g>
> > > https://www.thetaphi.de
> > > eMail: uwe@thetaphi.de
> > >
> > > > -----Original Message-----
> > > > From: Bram Van Dam <br...@intix.eu>
> > > > Sent: Friday, December 10, 2021 8:31 AM
> > > > To: 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/
> > > > [2] https://news.ycombinator.com/item?id=29504755
> > > >
> > > >
> > > > - Bram
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
>
>
> --
>
> http://www.needhamsoftware.com (work)
>
> http://www.the111shift.com (play)
>
>
>
>
> --
>
> http://www.needhamsoftware.com (work)
>
> http://www.the111shift.com (play)
>
>
RE: Log4J RCE vulnerability
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: Jason Gerlowski <ge...@gmail.com>
> Sent: Friday, December 10, 2021 7:16 PM
> To: dev@solr.apache.org
> 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 <uw...@thetaphi.de> 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: uwe@thetaphi.de
> >
> >
> >
> > From: Cassandra Targett <ca...@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 <uw...@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: uwe@thetaphi.de
> >
> >
> >
> > From: Gus Heck <gu...@gmail.com>
> > Sent: Friday, December 10, 2021 1:32 PM
> > To: dev@solr.apache.org
> > 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 <gu...@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 <uw...@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
> >
> > -----
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> > > -----Original Message-----
> > > From: Uwe Schindler <uw...@thetaphi.de>
> > > Sent: Friday, December 10, 2021 11:10 AM
> > > To: 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
> > > eMail: uwe@thetaphi.de
> > >
> > > > -----Original Message-----
> > > > From: Uwe Schindler <uw...@thetaphi.de>
> > > > Sent: Friday, December 10, 2021 10:35 AM
> > > > To: 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): 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: uwe@thetaphi.de
> > > >
> > > > > -----Original Message-----
> > > > > From: Bram Van Dam <br...@intix.eu>
> > > > > Sent: Friday, December 10, 2021 8:31 AM
> > > > > To: 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/
> > > > > [2] https://news.ycombinator.com/item?id=29504755
> > > > >
> > > > >
> > > > > - Bram
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
> >
> >
> > --
> >
> > http://www.needhamsoftware.com (work)
> >
> > http://www.the111shift.com (play)
> >
> >
> >
> >
> > --
> >
> > http://www.needhamsoftware.com (work)
> >
> > http://www.the111shift.com (play)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Log4J RCE vulnerability
Posted by Jason Gerlowski <ge...@gmail.com>.
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 <uw...@thetaphi.de> 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: uwe@thetaphi.de
>
>
>
> From: Cassandra Targett <ca...@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 <uw...@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: uwe@thetaphi.de
>
>
>
> From: Gus Heck <gu...@gmail.com>
> Sent: Friday, December 10, 2021 1:32 PM
> To: dev@solr.apache.org
> 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 <gu...@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 <uw...@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
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Uwe Schindler <uw...@thetaphi.de>
> > Sent: Friday, December 10, 2021 11:10 AM
> > To: 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
> > eMail: uwe@thetaphi.de
> >
> > > -----Original Message-----
> > > From: Uwe Schindler <uw...@thetaphi.de>
> > > Sent: Friday, December 10, 2021 10:35 AM
> > > To: 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): 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: uwe@thetaphi.de
> > >
> > > > -----Original Message-----
> > > > From: Bram Van Dam <br...@intix.eu>
> > > > Sent: Friday, December 10, 2021 8:31 AM
> > > > To: 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/
> > > > [2] https://news.ycombinator.com/item?id=29504755
> > > >
> > > >
> > > > - Bram
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
>
>
> --
>
> http://www.needhamsoftware.com (work)
>
> http://www.the111shift.com (play)
>
>
>
>
> --
>
> http://www.needhamsoftware.com (work)
>
> http://www.the111shift.com (play)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
RE: Log4J RCE vulnerability
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
From: Cassandra Targett <ca...@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 <uwe@thetaphi.de <ma...@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: uwe@thetaphi.de <ma...@thetaphi.de>
From: Gus Heck <gus.heck@gmail.com <ma...@gmail.com> >
Sent: Friday, December 10, 2021 1:32 PM
To: dev@solr.apache.org <ma...@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 < <ma...@gmail.com> gus.heck@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 < <ma...@thetaphi.de> uwe@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: <ma...@thetaphi.de> uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler < <ma...@thetaphi.de> uwe@thetaphi.de>
> Sent: Friday, December 10, 2021 11:10 AM
> To: <ma...@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: <ma...@thetaphi.de> uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Uwe Schindler < <ma...@thetaphi.de> uwe@thetaphi.de>
> > Sent: Friday, December 10, 2021 10:35 AM
> > To: <ma...@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: <ma...@thetaphi.de> uwe@thetaphi.de
> >
> > > -----Original Message-----
> > > From: Bram Van Dam < <ma...@intix.eu> bram.vandam@intix.eu>
> > > Sent: Friday, December 10, 2021 8:31 AM
> > > To: <ma...@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: <ma...@solr.apache.org> dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: <ma...@solr.apache.org> dev-help@solr.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: <ma...@solr.apache.org> dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: <ma...@solr.apache.org> dev-help@solr.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: <ma...@solr.apache.org> dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: <ma...@solr.apache.org> dev-help@solr.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: <ma...@solr.apache.org> dev-unsubscribe@solr.apache.org
For additional commands, e-mail: <ma...@solr.apache.org> dev-help@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)
RE: Log4J RCE vulnerability
Posted by Cassandra Targett <ca...@gmail.com>.
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 <uw...@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: uwe@thetaphi.de
>
> From: Gus Heck <gu...@gmail.com>
> Sent: Friday, December 10, 2021 1:32 PM
> To: dev@solr.apache.org
> 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 <gu...@gmail.com> wrote:
> > quote_type
> > 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 <uw...@thetaphi.de> wrote:
> > > quote_type
> > > 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: uwe@thetaphi.de
> > >
> > > > -----Original Message-----
> > > > From: Uwe Schindler <uw...@thetaphi.de>
> > > > Sent: Friday, December 10, 2021 11:10 AM
> > > > To: 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
> > > > eMail: uwe@thetaphi.de
> > > >
> > > > > -----Original Message-----
> > > > > From: Uwe Schindler <uw...@thetaphi.de>
> > > > > Sent: Friday, December 10, 2021 10:35 AM
> > > > > To: 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): 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: uwe@thetaphi.de
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Bram Van Dam <br...@intix.eu>
> > > > > > Sent: Friday, December 10, 2021 8:31 AM
> > > > > > To: 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/
> > > > > > [2] https://news.ycombinator.com/item?id=29504755
> > > > > >
> > > > > >
> > > > > > - Bram
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
RE: Log4J RCE vulnerability
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
From: Gus Heck <gu...@gmail.com>
Sent: Friday, December 10, 2021 1:32 PM
To: 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 < <ma...@gmail.com> gus.heck@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 < <ma...@thetaphi.de> uwe@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: <ma...@thetaphi.de> uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler < <ma...@thetaphi.de> uwe@thetaphi.de>
> Sent: Friday, December 10, 2021 11:10 AM
> To: <ma...@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: <ma...@thetaphi.de> uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Uwe Schindler < <ma...@thetaphi.de> uwe@thetaphi.de>
> > Sent: Friday, December 10, 2021 10:35 AM
> > To: <ma...@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: <ma...@thetaphi.de> uwe@thetaphi.de
> >
> > > -----Original Message-----
> > > From: Bram Van Dam < <ma...@intix.eu> bram.vandam@intix.eu>
> > > Sent: Friday, December 10, 2021 8:31 AM
> > > To: <ma...@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: <ma...@solr.apache.org> dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: <ma...@solr.apache.org> dev-help@solr.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: <ma...@solr.apache.org> dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: <ma...@solr.apache.org> dev-help@solr.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: <ma...@solr.apache.org> dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: <ma...@solr.apache.org> dev-help@solr.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: <ma...@solr.apache.org> dev-unsubscribe@solr.apache.org
For additional commands, e-mail: <ma...@solr.apache.org> dev-help@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)
Re: Log4J RCE vulnerability
Posted by Gus Heck <gu...@gmail.com>.
In progress already it seems
https://issues.apache.org/jira/browse/SOLR-15843
On Fri, Dec 10, 2021 at 7:29 AM Gus Heck <gu...@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 <uw...@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
>>
>> -----
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>> > -----Original Message-----
>> > From: Uwe Schindler <uw...@thetaphi.de>
>> > Sent: Friday, December 10, 2021 11:10 AM
>> > To: 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
>> > eMail: uwe@thetaphi.de
>> >
>> > > -----Original Message-----
>> > > From: Uwe Schindler <uw...@thetaphi.de>
>> > > Sent: Friday, December 10, 2021 10:35 AM
>> > > To: 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): 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: uwe@thetaphi.de
>> > >
>> > > > -----Original Message-----
>> > > > From: Bram Van Dam <br...@intix.eu>
>> > > > Sent: Friday, December 10, 2021 8:31 AM
>> > > > To: 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/
>> > > > [2] https://news.ycombinator.com/item?id=29504755
>> > > >
>> > > >
>> > > > - Bram
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> > > > For additional commands, e-mail: dev-help@solr.apache.org
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> > > For additional commands, e-mail: dev-help@solr.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> > For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Log4J RCE vulnerability
Posted by Gus Heck <gu...@gmail.com>.
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 <uw...@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
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Uwe Schindler <uw...@thetaphi.de>
> > Sent: Friday, December 10, 2021 11:10 AM
> > To: 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
> > eMail: uwe@thetaphi.de
> >
> > > -----Original Message-----
> > > From: Uwe Schindler <uw...@thetaphi.de>
> > > Sent: Friday, December 10, 2021 10:35 AM
> > > To: 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): 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: uwe@thetaphi.de
> > >
> > > > -----Original Message-----
> > > > From: Bram Van Dam <br...@intix.eu>
> > > > Sent: Friday, December 10, 2021 8:31 AM
> > > > To: 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/
> > > > [2] https://news.ycombinator.com/item?id=29504755
> > > >
> > > >
> > > > - Bram
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
RE: Log4J RCE vulnerability
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler <uw...@thetaphi.de>
> Sent: Friday, December 10, 2021 11:10 AM
> To: 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
> eMail: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Uwe Schindler <uw...@thetaphi.de>
> > Sent: Friday, December 10, 2021 10:35 AM
> > To: 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): 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: uwe@thetaphi.de
> >
> > > -----Original Message-----
> > > From: Bram Van Dam <br...@intix.eu>
> > > Sent: Friday, December 10, 2021 8:31 AM
> > > To: 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/
> > > [2] https://news.ycombinator.com/item?id=29504755
> > >
> > >
> > > - Bram
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Log4J RCE vulnerability
Posted by Bram Van Dam <br...@intix.eu>.
On 10/12/2021 11.10, Uwe Schindler wrote:
> 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!!! 😊
Very sneaky. Seems like logback handles these things a bit better.
Upgrading log4j to 2.15.0 seems to disable the parsing by default. This
version just hit maven central last night.
- Bram
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
RE: Log4J RCE vulnerability
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler <uw...@thetaphi.de>
> Sent: Friday, December 10, 2021 10:35 AM
> To: 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): 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: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Bram Van Dam <br...@intix.eu>
> > Sent: Friday, December 10, 2021 8:31 AM
> > To: 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/
> > [2] https://news.ycombinator.com/item?id=29504755
> >
> >
> > - Bram
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org