You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@solr.apache.org by "Soh Jia Yu, Eunice" <eu...@ntu.edu.sg> on 2021/12/15 05:55:25 UTC
Query on CVE-2021-45046
Hi,
We've implemented this step "Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class" from https://logging.apache.org/log4j/2.x/security.html for <solr_dir>/server/lib/ext.
We would like to check if <solr_dir>/contrib/prometheus-exporter/lib/log4j-core-2.13.2.jar needs to be mitigated in this manner as well, assuming two different solutions: 1) we use Prometheus for solr, and 2) we do not use Prometheus for solr?
Kind regards,
Eunice
________________________________
CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its contents.
Towards a sustainable earth: Print only when necessary. Thank you.
Re: Query on CVE-2021-45046
Posted by "Ing. Andrea Vettori" <a....@b2bires.com>.
Hello, yesterday I replaced the jars from 2.13.2 to 2.16 and so far no issues.
—
Ing. Andrea Vettori
Responsabile Sistemi Informativi
B2BIres s.r.l.
> On 15 Dec 2021, at 18:58, Alessandro Benedetti <a....@sease.io> wrote:
>
> I would also encourage you to do the upgrade first on QA/Staging rather
> than directly on production, where possible.
> This could prevent nasty binary incompatibilities where the Solr build
> expects certain methods from the compiled log4j library, that mismatch with
> the upgraded jar.
> And a crashed offline production environment is definitely not better than
> a potentially vulnerable one :)
>
> Cheers
> --------------------------
> Alessandro Benedetti
> Apache Lucene/Solr Committer
> Director, R&D Software Engineer, Search Consultant
>
> www.sease.io
>
>
> On Wed, 15 Dec 2021 at 16:54, Shawn Heisey <ap...@elyograg.org> wrote:
>
>> On 12/15/21 9:41 AM, Ing. Andrea Vettori wrote:
>>> Hello, is it safe to simply replace the jars in the solr lib/ext folder
>> with version 2.16 or are they hardcoded in scripts or meta-inf files ?
>>
>>
>> This appears to work correctly if the original version of log4j included
>> was 2.14.1. I have done this and had no problems. I replaced it with
>> 2.15.0 as 2.16.0 had not yet come out when I did that testing.
>>
>> But I have not tried it with Solr versions shipping with any log4j
>> version other than 2.14.1, or with a 2.16.0 replacement. I have no idea
>> whether that would work. If the log4j team have done a good job of
>> keeping the API stable, I think it would work, but I do not have any
>> knowledge about that. You would be better off asking the log4j project
>> about API compatibility between versions.
>>
>> Thanks,
>> Shawn
>>
>>
Re: Query on CVE-2021-45046
Posted by Alessandro Benedetti <a....@sease.io>.
I would also encourage you to do the upgrade first on QA/Staging rather
than directly on production, where possible.
This could prevent nasty binary incompatibilities where the Solr build
expects certain methods from the compiled log4j library, that mismatch with
the upgraded jar.
And a crashed offline production environment is definitely not better than
a potentially vulnerable one :)
Cheers
--------------------------
Alessandro Benedetti
Apache Lucene/Solr Committer
Director, R&D Software Engineer, Search Consultant
www.sease.io
On Wed, 15 Dec 2021 at 16:54, Shawn Heisey <ap...@elyograg.org> wrote:
> On 12/15/21 9:41 AM, Ing. Andrea Vettori wrote:
> > Hello, is it safe to simply replace the jars in the solr lib/ext folder
> with version 2.16 or are they hardcoded in scripts or meta-inf files ?
>
>
> This appears to work correctly if the original version of log4j included
> was 2.14.1. I have done this and had no problems. I replaced it with
> 2.15.0 as 2.16.0 had not yet come out when I did that testing.
>
> But I have not tried it with Solr versions shipping with any log4j
> version other than 2.14.1, or with a 2.16.0 replacement. I have no idea
> whether that would work. If the log4j team have done a good job of
> keeping the API stable, I think it would work, but I do not have any
> knowledge about that. You would be better off asking the log4j project
> about API compatibility between versions.
>
> Thanks,
> Shawn
>
>
Re: Query on CVE-2021-45046
Posted by Shawn Heisey <ap...@elyograg.org>.
On 12/15/21 9:41 AM, Ing. Andrea Vettori wrote:
> Hello, is it safe to simply replace the jars in the solr lib/ext folder with version 2.16 or are they hardcoded in scripts or meta-inf files ?
This appears to work correctly if the original version of log4j included
was 2.14.1. I have done this and had no problems. I replaced it with
2.15.0 as 2.16.0 had not yet come out when I did that testing.
But I have not tried it with Solr versions shipping with any log4j
version other than 2.14.1, or with a 2.16.0 replacement. I have no idea
whether that would work. If the log4j team have done a good job of
keeping the API stable, I think it would work, but I do not have any
knowledge about that. You would be better off asking the log4j project
about API compatibility between versions.
Thanks,
Shawn
Re: Query on CVE-2021-45046
Posted by "Ing. Andrea Vettori" <a....@b2bires.com>.
Hello, is it safe to simply replace the jars in the solr lib/ext folder with version 2.16 or are they hardcoded in scripts or meta-inf files ?
Thanks
—
Ing. Andrea Vettori
Responsabile Sistemi Informativi
B2BIres s.r.l.
> On 15 Dec 2021, at 17:32, Shawn Heisey <ap...@elyograg.org> wrote:
>
> On 12/14/21 10:55 PM, Soh Jia Yu, Eunice wrote:
>> We've implemented this step "Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class" from https://logging.apache.org/log4j/2.x/security.html for <solr_dir>/server/lib/ext.
>
> Interesting way to eliminate the problem. That would certainly work.
>
>> We would like to check if <solr_dir>/contrib/prometheus-exporter/lib/log4j-core-2.13.2.jar needs to be mitigated in this manner as well, assuming two different solutions: 1) we use Prometheus for solr, and 2) we do not use Prometheus for solr?
>
> Someone on our team looked into this. No user-provided strings are logged by this module, so it should not be vulnerable. But if you want to be thorough and absolutely sure, you can modify the log4j-core jar like you did for Solr.
>
> Thanks,
> Shawn
>
>
Re: Query on CVE-2021-45046
Posted by Shawn Heisey <ap...@elyograg.org>.
On 12/14/21 10:55 PM, Soh Jia Yu, Eunice wrote:
> We've implemented this step "Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class" from https://logging.apache.org/log4j/2.x/security.html for <solr_dir>/server/lib/ext.
Interesting way to eliminate the problem. That would certainly work.
> We would like to check if <solr_dir>/contrib/prometheus-exporter/lib/log4j-core-2.13.2.jar needs to be mitigated in this manner as well, assuming two different solutions: 1) we use Prometheus for solr, and 2) we do not use Prometheus for solr?
Someone on our team looked into this. No user-provided strings are
logged by this module, so it should not be vulnerable. But if you want
to be thorough and absolutely sure, you can modify the log4j-core jar
like you did for Solr.
Thanks,
Shawn