Re: [JENKINS] Lucene-9.x-Linux (64bit/jdk-17) - Build # 465 - Failure!

[Dawid Weiss]

I've found a workaround, I hope, and enabled modules on main again. Let's
see if there are any other surprises from jenkins. If builds pass, I'll do
the same on 9x.

D.

On Sat, Dec 18, 2021 at 11:33 PM Dawid Weiss  wrote:

>
> I'm sorry then, I'll have to revert until a solution is found. I don't
> think this is easily fixable. I'm tired.
>
> Dawid
>
> On Sat, Dec 18, 2021 at 11:31 PM Uwe Schindler  wrote:
>
>> Hi,
>> Unfortunately I have to pass runtime Java for randomization. I know it
>> would work with later java versions, but Gradle does not work with jdk18
>> preview. The way how the randomizer is coded is: always pass jdk11 to run
>> Gradle (which is the Jenkins config for the job) and pass the test runner
>> JVM with runtime env var by the randomizer. This also includes the test
>> runner args, which are all passed as env vars.
>>
>> Uwe
>>
>> Am 18. Dezember 2021 22:18:02 UTC schrieb Dawid Weiss <
>> dawid.we...@gmail.com>:
>> >It doesn't work if you pass a different runtime.java.home. It does work
>> if
>> >you're using the same gradle/runtime jvm. Seems like gradle emits an
>> empty
>> >sourcepath which changes runtime javac behavior:
>> >
>> >-sourcepath
>> >""
>> >
>> >I don't know if there's any workaround for this.
>> >
>> >D.
>> >
>> >On Sat, Dec 18, 2021 at 11:02 PM Dawid Weiss 
>> wrote:
>> >
>> >>
>> >> I see it on Jenkins but can't reproduce this on any system I have
>> access
>> >> to (Linux, Windows). We don't do anything special for javac - the
>> arguments
>> >> there are collected from within gradle... So weird.
>> >>
>> >> D.
>> >>
>> >> On Sat, Dec 18, 2021 at 9:34 PM Uwe Schindler  wrote:
>> >>
>> >>> There's also the same bug in javac. It fails with an error in every
>> >>> source file.
>> >>>
>> >>> Uwe
>> >>>
>> >>> Am 18. Dezember 2021 20:13:09 UTC schrieb Dawid Weiss <
>> >>> dawid.we...@gmail.com>:
>> 
>> 
>>  Eh. It seems this bug in ECJ is not predictable - it fails on the
>> CI, it
>>  doesn't fail for me locally.
>>  https://bugs.eclipse.org/bugs/show_bug.cgi?id=569833
>> 
>>  >* Task :lucene:core:ecjLintMain* FAILED
>>  --
>>  1. ERROR in
>> /home/jenkins/workspace/Lucene-9.x-Linux/lucene/core/src/java/module-info.java
>> (at line 22)
>>  exports org.apache.lucene.analysis;
>>  ^^
>>  The package org.apache.lucene.analysis does not exist or is empty
>> 
>> 
>>  On Sat, Dec 18, 2021 at 9:08 PM Policeman Jenkins Server <
>>  jenk...@thetaphi.de> wrote:
>> 
>> > Build: https://jenkins.thetaphi.de/job/Lucene-9.x-Linux/465/
>> > Java: 64bit/jdk-17 -XX:+UseCompressedOops -XX:+UseSerialGC
>> >
>> > No tests ran.
>> >
>> >
>> -
>> > To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: builds-h...@lucene.apache.org
>> 
>>  --
>> >>> Uwe Schindler
>> >>> Achterdiek 19, 28357 Bremen
>> >>> https://www.thetaphi.de
>> >>>
>> >>
>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
>

Re: [JENKINS] Lucene-9.x-Linux (64bit/jdk-17) - Build # 465 - Failure!

[Dawid Weiss]

I'm sorry then, I'll have to revert until a solution is found. I don't
think this is easily fixable. I'm tired.

Dawid

On Sat, Dec 18, 2021 at 11:31 PM Uwe Schindler  wrote:

> Hi,
> Unfortunately I have to pass runtime Java for randomization. I know it
> would work with later java versions, but Gradle does not work with jdk18
> preview. The way how the randomizer is coded is: always pass jdk11 to run
> Gradle (which is the Jenkins config for the job) and pass the test runner
> JVM with runtime env var by the randomizer. This also includes the test
> runner args, which are all passed as env vars.
>
> Uwe
>
> Am 18. Dezember 2021 22:18:02 UTC schrieb Dawid Weiss <
> dawid.we...@gmail.com>:
> >It doesn't work if you pass a different runtime.java.home. It does work if
> >you're using the same gradle/runtime jvm. Seems like gradle emits an empty
> >sourcepath which changes runtime javac behavior:
> >
> >-sourcepath
> >""
> >
> >I don't know if there's any workaround for this.
> >
> >D.
> >
> >On Sat, Dec 18, 2021 at 11:02 PM Dawid Weiss 
> wrote:
> >
> >>
> >> I see it on Jenkins but can't reproduce this on any system I have access
> >> to (Linux, Windows). We don't do anything special for javac - the
> arguments
> >> there are collected from within gradle... So weird.
> >>
> >> D.
> >>
> >> On Sat, Dec 18, 2021 at 9:34 PM Uwe Schindler  wrote:
> >>
> >>> There's also the same bug in javac. It fails with an error in every
> >>> source file.
> >>>
> >>> Uwe
> >>>
> >>> Am 18. Dezember 2021 20:13:09 UTC schrieb Dawid Weiss <
> >>> dawid.we...@gmail.com>:
> 
> 
>  Eh. It seems this bug in ECJ is not predictable - it fails on the CI,
> it
>  doesn't fail for me locally.
>  https://bugs.eclipse.org/bugs/show_bug.cgi?id=569833
> 
>  >* Task :lucene:core:ecjLintMain* FAILED
>  --
>  1. ERROR in
> /home/jenkins/workspace/Lucene-9.x-Linux/lucene/core/src/java/module-info.java
> (at line 22)
>  exports org.apache.lucene.analysis;
>  ^^
>  The package org.apache.lucene.analysis does not exist or is empty
> 
> 
>  On Sat, Dec 18, 2021 at 9:08 PM Policeman Jenkins Server <
>  jenk...@thetaphi.de> wrote:
> 
> > Build: https://jenkins.thetaphi.de/job/Lucene-9.x-Linux/465/
> > Java: 64bit/jdk-17 -XX:+UseCompressedOops -XX:+UseSerialGC
> >
> > No tests ran.
> >
> > -
> > To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: builds-h...@lucene.apache.org
> 
>  --
> >>> Uwe Schindler
> >>> Achterdiek 19, 28357 Bremen
> >>> https://www.thetaphi.de
> >>>
> >>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>

Re: [JENKINS] Lucene-9.x-Linux (64bit/jdk-17) - Build # 465 - Failure!

[Uwe Schindler]

Hi,
Unfortunately I have to pass runtime Java for randomization. I know it would 
work with later java versions, but Gradle does not work with jdk18 preview. The 
way how the randomizer is coded is: always pass jdk11 to run Gradle (which is 
the Jenkins config for the job) and pass the test runner JVM with runtime env 
var by the randomizer. This also includes the test runner args, which are all 
passed as env vars.

Uwe

Am 18. Dezember 2021 22:18:02 UTC schrieb Dawid Weiss :
>It doesn't work if you pass a different runtime.java.home. It does work if
>you're using the same gradle/runtime jvm.  Seems like gradle emits an empty
>sourcepath which changes runtime javac behavior:
>
>-sourcepath
>""
>
>I don't know if there's any workaround for this.
>
>D.
>
>On Sat, Dec 18, 2021 at 11:02 PM Dawid Weiss  wrote:
>
>>
>> I see it on Jenkins but can't reproduce this on any system I have access
>> to (Linux, Windows). We don't do anything special for javac - the arguments
>> there are collected from within gradle... So weird.
>>
>> D.
>>
>> On Sat, Dec 18, 2021 at 9:34 PM Uwe Schindler  wrote:
>>
>>> There's also the same bug in javac. It fails with an error in every
>>> source file.
>>>
>>> Uwe
>>>
>>> Am 18. Dezember 2021 20:13:09 UTC schrieb Dawid Weiss <
>>> dawid.we...@gmail.com>:


 Eh. It seems this bug in ECJ is not predictable - it fails on the CI, it
 doesn't fail for me locally.
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=569833

 >* Task :lucene:core:ecjLintMain* FAILED
 --
 1. ERROR in 
 /home/jenkins/workspace/Lucene-9.x-Linux/lucene/core/src/java/module-info.java
  (at line 22)
exports org.apache.lucene.analysis;
^^
 The package org.apache.lucene.analysis does not exist or is empty


 On Sat, Dec 18, 2021 at 9:08 PM Policeman Jenkins Server <
 jenk...@thetaphi.de> wrote:

> Build: https://jenkins.thetaphi.de/job/Lucene-9.x-Linux/465/
> Java: 64bit/jdk-17 -XX:+UseCompressedOops -XX:+UseSerialGC
>
> No tests ran.
>
> -
> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
> For additional commands, e-mail: builds-h...@lucene.apache.org

 --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de
>>>
>>

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Re: [JENKINS] Lucene-9.x-Linux (64bit/jdk-17) - Build # 465 - Failure!

[Dawid Weiss]

It doesn't work if you pass a different runtime.java.home. It does work if
you're using the same gradle/runtime jvm.  Seems like gradle emits an empty
sourcepath which changes runtime javac behavior:

-sourcepath
""

I don't know if there's any workaround for this.

D.

On Sat, Dec 18, 2021 at 11:02 PM Dawid Weiss  wrote:

>
> I see it on Jenkins but can't reproduce this on any system I have access
> to (Linux, Windows). We don't do anything special for javac - the arguments
> there are collected from within gradle... So weird.
>
> D.
>
> On Sat, Dec 18, 2021 at 9:34 PM Uwe Schindler  wrote:
>
>> There's also the same bug in javac. It fails with an error in every
>> source file.
>>
>> Uwe
>>
>> Am 18. Dezember 2021 20:13:09 UTC schrieb Dawid Weiss <
>> dawid.we...@gmail.com>:
>>>
>>>
>>> Eh. It seems this bug in ECJ is not predictable - it fails on the CI, it
>>> doesn't fail for me locally.
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=569833
>>>
>>> >* Task :lucene:core:ecjLintMain* FAILED
>>> --
>>> 1. ERROR in 
>>> /home/jenkins/workspace/Lucene-9.x-Linux/lucene/core/src/java/module-info.java
>>>  (at line 22)
>>> exports org.apache.lucene.analysis;
>>> ^^
>>> The package org.apache.lucene.analysis does not exist or is empty
>>>
>>>
>>> On Sat, Dec 18, 2021 at 9:08 PM Policeman Jenkins Server <
>>> jenk...@thetaphi.de> wrote:
>>>
 Build: https://jenkins.thetaphi.de/job/Lucene-9.x-Linux/465/
 Java: 64bit/jdk-17 -XX:+UseCompressedOops -XX:+UseSerialGC

 No tests ran.

 -
 To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
 For additional commands, e-mail: builds-h...@lucene.apache.org
>>>
>>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
>

Re: [JENKINS] Lucene-9.x-Linux (64bit/jdk-17) - Build # 465 - Failure!

[Dawid Weiss]

I see it on Jenkins but can't reproduce this on any system I have access to
(Linux, Windows). We don't do anything special for javac - the arguments
there are collected from within gradle... So weird.

D.

On Sat, Dec 18, 2021 at 9:34 PM Uwe Schindler  wrote:

> There's also the same bug in javac. It fails with an error in every source
> file.
>
> Uwe
>
> Am 18. Dezember 2021 20:13:09 UTC schrieb Dawid Weiss <
> dawid.we...@gmail.com>:
>>
>>
>> Eh. It seems this bug in ECJ is not predictable - it fails on the CI, it
>> doesn't fail for me locally.
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=569833
>>
>> >* Task :lucene:core:ecjLintMain* FAILED
>> --
>> 1. ERROR in 
>> /home/jenkins/workspace/Lucene-9.x-Linux/lucene/core/src/java/module-info.java
>>  (at line 22)
>>  exports org.apache.lucene.analysis;
>>  ^^
>> The package org.apache.lucene.analysis does not exist or is empty
>>
>>
>> On Sat, Dec 18, 2021 at 9:08 PM Policeman Jenkins Server <
>> jenk...@thetaphi.de> wrote:
>>
>>> Build: https://jenkins.thetaphi.de/job/Lucene-9.x-Linux/465/
>>> Java: 64bit/jdk-17 -XX:+UseCompressedOops -XX:+UseSerialGC
>>>
>>> No tests ran.
>>>
>>> -
>>> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: builds-h...@lucene.apache.org
>>
>> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>

Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set

[Gus Heck]

Thinking about it some more, maybe the problem with my suggestion is
the table on that page is organized by the library version and, if
unmitigated, the version of the library is still a problem. Maybe another
way to be clearer about it and avoid rewriting things that people have
already read would be to add independent entries to the security news page
for the newer CVE's

On Sat, Dec 18, 2021 at 12:20 PM Gus Heck  wrote:

> I think perhaps in the shock of such a deep and surprising vulnerability
> with such high visibility, we've begun to break with how we normally handle
> CVE's that don't apply to our usage of the library. Previously, they just
> got added to the list of known false positives
> .
> Normally we wouldn't even mention them on the security news page, but
> because of the high visibility we should simply have a line mentioning that
> these two CVE's are on our false positives page and explain details there.
> The wiki would provide revision history automatically.
>
> On Sat, Dec 18, 2021 at 11:25 AM Jan Høydahl 
> wrote:
>
>> We make edits to the log4j advisory almost daily, see
>> https://github.com/apache/solr-site/commits/e10a6a9fe0eed8dcba3ad1a076c8208e014e76ff/content/solr/security/2021-12-10-cve-2021-44228.md
>> I wonder if we should include a "Revision history" paragraph in the
>> advisory for transparency?
>>
>> Jan
>>
>> 15. des. 2021 kl. 19:09 skrev Uwe Schindler :
>>
>> Hi all, I prepared a PR about the followup CVE-2021-45046:
>> https://github.com/apache/solr-site/pull/59
>>
>> Please verify and make suggestion. I will merge this into main/production
>> later.
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> *From:* Uwe Schindler 
>> *Sent:* Wednesday, December 15, 2021 3:31 PM
>> *To:* 'dev@lucene.apache.org' 
>> *Subject:* RE: Log4j < 2.15.0 may still be vulnerable even if
>> -Dlog4j2.formatMsgNoLookups=true is set
>>
>> We should add this to the webpage. Another one asked on the security
>> mailing list.
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> *From:* Gus Heck 
>> *Sent:* Wednesday, December 15, 2021 12:39 AM
>> *To:* dev 
>> *Subject:* Re: Log4j < 2.15.0 may still be vulnerable even if
>> -Dlog4j2.formatMsgNoLookups=true is set
>>
>> Perhaps we could tweak it to say that the system property fix is
>> sufficient *for Solr* (i.e. not imply that it is a valid work around for
>> all cases)
>>
>> On Tue, Dec 14, 2021 at 6:20 PM Uwe Schindler  wrote:
>>
>> The other attack vectors are also not possible with Solr:
>>
>> - Logger.printf("%s", userInput) is not used
>> - custom message factory is not used
>>
>> Uwe
>> Am 14. Dezember 2021 22:59:26 UTC schrieb Uwe Schindler > >:
>>
>> It is still a valid mitigation.
>>
>> Mike Drobban I explained it. MDC is the other attack vector and that's
>> not an issue with Solr.
>>
>> Please accept this, just because the documentation of log4j changes,
>> there's no additional risk. We may update the mitigation to mention that in
>> Solr's case the system property is fine.
>>
>> Uwe
>> Am 14. Dezember 2021 22:52:29 UTC schrieb solr :
>>
>> Ok.
>>
>> But FTR - apache/log4j has discredited just setting the system property as a 
>> mitigation measure, so I still think the SOLR security-page should be 
>> changed to not list this as a valid mitigation:
>>
>> https://logging.apache.org/log4j/2.x/security.html
>> "Older (discredited) mitigation measures
>>
>> This page previously mentioned other mitigation measures, but we discovered 
>> that these measures only limit exposure while leaving some attack vectors 
>> open.
>>
>> Other insufficient mitigation measures are: setting system property 
>> log4j2.formatMsgNoLookups or environment variable 
>> LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the 
>> logging configuration to disable message lookups with %m{nolookups}, 
>> %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
>> “
>>
>> Regards,
>>
>>
>> Fredrik
>>
>>
>> --
>> Fredrik Rødland   Cell:+47 99 21 98 17
>> Maisen Pedersens vei 1Twitter: @fredrikr
>> NO-1363 Høvik, NORWAY flickr:  http://www.flickr.com/fmmr/
>> http://rodland.no about.me http://about.me/fmr
>>
>> On 14 Dec 2021, at 23:44, Mike Drob  wrote:
>>
>> The MDC Patterns used by solr are for the collection, shard, replica, core 
>> and node names, and a potential trace id. All of those are restricted to 
>> alphanumeric, no special characters like $ or { needed for the injection. 
>> And trying to access a collection that didn’t exist Returns 404 without 
>> logging.
>>
>> Upgrading is always going to be more complete, but I think we’re still ok 
>> for now, at least until the next iteration of this attack 

Re: [JENKINS] Lucene-9.x-Linux (64bit/jdk-17) - Build # 465 - Failure!

[Uwe Schindler]

There's also the same bug in javac. It fails with an error in every source file.

Uwe

Am 18. Dezember 2021 20:13:09 UTC schrieb Dawid Weiss :
>Eh. It seems this bug in ECJ is not predictable - it fails on the CI, it
>doesn't fail for me locally.
>https://bugs.eclipse.org/bugs/show_bug.cgi?id=569833
>
>>* Task :lucene:core:ecjLintMain* FAILED
>--
>1. ERROR in 
>/home/jenkins/workspace/Lucene-9.x-Linux/lucene/core/src/java/module-info.java
>(at line 22)
>   exports org.apache.lucene.analysis;
>   ^^
>The package org.apache.lucene.analysis does not exist or is empty
>
>
>On Sat, Dec 18, 2021 at 9:08 PM Policeman Jenkins Server <
>jenk...@thetaphi.de> wrote:
>
>> Build: https://jenkins.thetaphi.de/job/Lucene-9.x-Linux/465/
>> Java: 64bit/jdk-17 -XX:+UseCompressedOops -XX:+UseSerialGC
>>
>> No tests ran.
>>
>> -
>> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: builds-h...@lucene.apache.org

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Re: [JENKINS] Lucene-9.x-Linux (64bit/jdk-17) - Build # 465 - Failure!

[Dawid Weiss]

Eh. It seems this bug in ECJ is not predictable - it fails on the CI, it
doesn't fail for me locally.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=569833

>* Task :lucene:core:ecjLintMain* FAILED
--
1. ERROR in 
/home/jenkins/workspace/Lucene-9.x-Linux/lucene/core/src/java/module-info.java
(at line 22)
exports org.apache.lucene.analysis;
^^
The package org.apache.lucene.analysis does not exist or is empty


On Sat, Dec 18, 2021 at 9:08 PM Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: https://jenkins.thetaphi.de/job/Lucene-9.x-Linux/465/
> Java: 64bit/jdk-17 -XX:+UseCompressedOops -XX:+UseSerialGC
>
> No tests ran.
>
> -
> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
> For additional commands, e-mail: builds-h...@lucene.apache.org

Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set

[Gus Heck]

I think perhaps in the shock of such a deep and surprising vulnerability
with such high visibility, we've begun to break with how we normally handle
CVE's that don't apply to our usage of the library. Previously, they just
got added to the list of known false positives
.
Normally we wouldn't even mention them on the security news page, but
because of the high visibility we should simply have a line mentioning that
these two CVE's are on our false positives page and explain details there.
The wiki would provide revision history automatically.

On Sat, Dec 18, 2021 at 11:25 AM Jan Høydahl  wrote:

> We make edits to the log4j advisory almost daily, see
> https://github.com/apache/solr-site/commits/e10a6a9fe0eed8dcba3ad1a076c8208e014e76ff/content/solr/security/2021-12-10-cve-2021-44228.md
> I wonder if we should include a "Revision history" paragraph in the
> advisory for transparency?
>
> Jan
>
> 15. des. 2021 kl. 19:09 skrev Uwe Schindler :
>
> Hi all, I prepared a PR about the followup CVE-2021-45046:
> https://github.com/apache/solr-site/pull/59
>
> Please verify and make suggestion. I will merge this into main/production
> later.
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> *From:* Uwe Schindler 
> *Sent:* Wednesday, December 15, 2021 3:31 PM
> *To:* 'dev@lucene.apache.org' 
> *Subject:* RE: Log4j < 2.15.0 may still be vulnerable even if
> -Dlog4j2.formatMsgNoLookups=true is set
>
> We should add this to the webpage. Another one asked on the security
> mailing list.
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> *From:* Gus Heck 
> *Sent:* Wednesday, December 15, 2021 12:39 AM
> *To:* dev 
> *Subject:* Re: Log4j < 2.15.0 may still be vulnerable even if
> -Dlog4j2.formatMsgNoLookups=true is set
>
> Perhaps we could tweak it to say that the system property fix is
> sufficient *for Solr* (i.e. not imply that it is a valid work around for
> all cases)
>
> On Tue, Dec 14, 2021 at 6:20 PM Uwe Schindler  wrote:
>
> The other attack vectors are also not possible with Solr:
>
> - Logger.printf("%s", userInput) is not used
> - custom message factory is not used
>
> Uwe
> Am 14. Dezember 2021 22:59:26 UTC schrieb Uwe Schindler :
>
> It is still a valid mitigation.
>
> Mike Drobban I explained it. MDC is the other attack vector and that's not
> an issue with Solr.
>
> Please accept this, just because the documentation of log4j changes,
> there's no additional risk. We may update the mitigation to mention that in
> Solr's case the system property is fine.
>
> Uwe
> Am 14. Dezember 2021 22:52:29 UTC schrieb solr :
>
> Ok.
>
> But FTR - apache/log4j has discredited just setting the system property as a 
> mitigation measure, so I still think the SOLR security-page should be changed 
> to not list this as a valid mitigation:
>
> https://logging.apache.org/log4j/2.x/security.html
> "Older (discredited) mitigation measures
>
> This page previously mentioned other mitigation measures, but we discovered 
> that these measures only limit exposure while leaving some attack vectors 
> open.
>
> Other insufficient mitigation measures are: setting system property 
> log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS 
> to true for releases >= 2.10, or modifying the logging configuration to 
> disable message lookups with %m{nolookups}, %msg{nolookups} or 
> %message{nolookups} for releases >= 2.7 and <= 2.14.1.
> “
>
> Regards,
>
>
> Fredrik
>
>
> --
> Fredrik Rødland   Cell:+47 99 21 98 17
> Maisen Pedersens vei 1Twitter: @fredrikr
> NO-1363 Høvik, NORWAY flickr:  http://www.flickr.com/fmmr/
> http://rodland.no about.me http://about.me/fmr
>
> On 14 Dec 2021, at 23:44, Mike Drob  wrote:
>
> The MDC Patterns used by solr are for the collection, shard, replica, core 
> and node names, and a potential trace id. All of those are restricted to 
> alphanumeric, no special characters like $ or { needed for the injection. And 
> trying to access a collection that didn’t exist Returns 404 without logging.
>
> Upgrading is always going to be more complete, but I think we’re still ok for 
> now, at least until the next iteration of this attack surfaces.
>
>
>
> On Tue, Dec 14, 2021 at 3:37 PM solr  wrote:
> Only setting -Dlog4j2.formatMsgNoLookups=true might not be enough to mitigate 
> the log4j vulnerability.
>
> See https://github.com/kmindi/log4shell-vulnerable-app
> “So even with LOG4J_FORMAT_MSG_NO_LOOKUPS true version 2.14.1 of log4j is 
> vulnerable when using ThreadContextMap in PatternLayout.”
>
> ThreadContext.put(key, value) is used under the hood by MDC.  I’m not sure 
> wether any user-input is actually stored in MDC in SOLR.
>
>
> Probably this should be updated: 
> 

Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set

[Jan Høydahl]

We make edits to the log4j advisory almost daily, see 
https://github.com/apache/solr-site/commits/e10a6a9fe0eed8dcba3ad1a076c8208e014e76ff/content/solr/security/2021-12-10-cve-2021-44228.md
I wonder if we should include a "Revision history" paragraph in the advisory 
for transparency?

Jan

> 15. des. 2021 kl. 19:09 skrev Uwe Schindler :
> 
> Hi all, I prepared a PR about the followup CVE-2021-45046: 
> https://github.com/apache/solr-site/pull/59 
> 
>  
> Please verify and make suggestion. I will merge this into main/production 
> later.
>  
> Uwe
>  
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de 
> eMail: u...@thetaphi.de 
>  
> From: Uwe Schindler mailto:u...@thetaphi.de>> 
> Sent: Wednesday, December 15, 2021 3:31 PM
> To: 'dev@lucene.apache.org ' 
> mailto:dev@lucene.apache.org>>
> Subject: RE: Log4j < 2.15.0 may still be vulnerable even if 
> -Dlog4j2.formatMsgNoLookups=true is set
>  
> We should add this to the webpage. Another one asked on the security mailing 
> list.
>  
> Uwe
>  
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de 
> eMail: u...@thetaphi.de 
>  
> From: Gus Heck mailto:gus.h...@gmail.com>> 
> Sent: Wednesday, December 15, 2021 12:39 AM
> To: dev mailto:dev@lucene.apache.org>>
> Subject: Re: Log4j < 2.15.0 may still be vulnerable even if 
> -Dlog4j2.formatMsgNoLookups=true is set
>  
> Perhaps we could tweak it to say that the system property fix is sufficient 
> *for Solr* (i.e. not imply that it is a valid work around for all cases)
>  
> On Tue, Dec 14, 2021 at 6:20 PM Uwe Schindler  > wrote:
>> The other attack vectors are also not possible with Solr:
>> 
>> - Logger.printf("%s", userInput) is not used
>> - custom message factory is not used
>> 
>> Uwe
>> 
>> Am 14. Dezember 2021 22:59:26 UTC schrieb Uwe Schindler > >:
>>> It is still a valid mitigation.
>>> 
>>> Mike Drobban I explained it. MDC is the other attack vector and that's not 
>>> an issue with Solr.
>>> 
>>> Please accept this, just because the documentation of log4j changes, 
>>> there's no additional risk. We may update the mitigation to mention that in 
>>> Solr's case the system property is fine.
>>> 
>>> Uwe
>>> 
>>> Am 14. Dezember 2021 22:52:29 UTC schrieb solr >> >:
 Ok.
 
 But FTR - apache/log4j has discredited just setting the system property as 
 a mitigation measure, so I still think the SOLR security-page should be 
 changed to not list this as a valid mitigation:
 
 https://logging.apache.org/log4j/2.x/security.html 
 
 "Older (discredited) mitigation measures
 
 This page previously mentioned other mitigation measures, but we 
 discovered that these measures only limit exposure while leaving some 
 attack vectors open.
 
 Other insufficient mitigation measures are: setting system property 
 log4j2.formatMsgNoLookups or environment variable 
 LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the 
 logging configuration to disable message lookups with %m{nolookups}, 
 %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
 “
 
 Regards,
 
 
 Fredrik
 
 
 --
 Fredrik Rødland   Cell:+47 99 21 98 17
 Maisen Pedersens vei 1Twitter: @fredrikr
 NO-1363 Høvik, NORWAY flickr:  http://www.flickr.com/fmmr/ 
 
 http://rodland.no  about.me 
  http://about.me/fmr 
 
> On 14 Dec 2021, at 23:44, Mike Drob  > wrote:
> 
> The MDC Patterns used by solr are for the collection, shard, replica, 
> core and node names, and a potential trace id. All of those are 
> restricted to alphanumeric, no special characters like $ or { needed for 
> the injection. And trying to access a collection that didn’t exist 
> Returns 404 without logging.
> 
> Upgrading is always going to be more complete, but I think we’re still ok 
> for now, at least until the next iteration of this attack surfaces.
> 
> 
> 
> On Tue, Dec 14, 2021 at 3:37 PM solr  > wrote:
> Only setting -Dlog4j2.formatMsgNoLookups=true might not be enough to 
> mitigate the log4j vulnerability.
> 
> See https://github.com/kmindi/log4shell-vulnerable-app 
> 
> “So even with LOG4J_FORMAT_MSG_NO_LOOKUPS true version 2.14.1 of log4j is 
> vulnerable when using ThreadContextMap in PatternLayout.”
> 
>