You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by solr <fr...@rodland.no> on 2021/12/14 21:10:26 UTC
Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
Regards,
Fredrik
--
Fredrik Rødland Cell: +47 99 21 98 17
Maisen Pedersens vei 1 Twitter: @fredrikr
NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
http://rodland.no about.me http://about.me/fmr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
From: Gus Heck <gu...@gmail.com>
Sent: Wednesday, December 15, 2021 12:39 AM
To: dev <de...@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 <uwe@thetaphi.de <ma...@thetaphi.de> > 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 <uwe@thetaphi.de <ma...@thetaphi.de> >:
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 <fredrik@rodland.no <ma...@rodland.no> >:
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 1 Twitter: @fredrikr
NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
http://rodland.no about.me <http://about.me> http://about.me/fmr
On 14 Dec 2021, at 23:44, Mike Drob <mdrob@mdrob.com <ma...@mdrob.com> > 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 <fredrik@rodland.no <ma...@rodland.no> > 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
Regards,
Fredrik
--
Fredrik Rødland Cell: +47 99 21 98 17
Maisen Pedersens vei 1 Twitter: @fredrikr
NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
http://rodland.no about.me <http://about.me> http://about.me/fmr
_____
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
_____
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
If your organization requires, you can do that manually, as described in the security advisory. Log4j 2.17 is backwards compatible down to 2.0.
Delete the old jar files, download newer versions from Maven Central (or log4j website all in one) and drop them where the older version were before. Plain simple.
Uwe
Am 22. Dezember 2021 19:09:46 UTC schrieb Michael Schumann <sc...@adobe.com.INVALID>:
>That is the case here at Adobe. Even though we have multiple mitigations in place for Solr (configuration, Java 11), we will be required to upgrade to Log4J version 2.17.
>
>From: Gus Heck <gu...@gmail.com>
>Reply-To: "dev@solr.apache.org" <de...@solr.apache.org>
>Date: Tuesday, December 21, 2021 at 1:21 PM
>To: "dev@solr.apache.org" <de...@solr.apache.org>
>Subject: Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
>
>For what it's worth, I'm seeing IT depts not wanting to track exceptions to the rule (such as solr) and requiring the library upgrades period.
>
>On Tue, Dec 21, 2021 at 1:48 PM David Smiley <ds...@apache.org>> wrote:
>(switching to dev@solr.apache.org<ma...@solr.apache.org>; the O.P. unfortunatelysent this to Lucene)
>
>BTW I'm having a good conversation[1] with Ralph Goers on the Log4j2 PMC about the efficacy of log4j2.formatMsgNoLookups. So far I've learned nothing that concerns me and I feel better in fact about other apps using this mitigation.
>[1]: https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fkgh63sncrsm2bls884pg87mnt8vqztmz&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662931434%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8V9PGM%2B6wzpqrE9hHt5W3CsZrej%2FTTD%2Ba0gjEz63yZU%3D&reserved=0>
>
>I think we should update our security news to reference this conversation for those that want to dig deeper as evidence. The fact that Log4j's security page refers to this technique as "discredited" puts us in a position where we have to acknowledge this word on their part and defend ourselves so it's clear our guidance came out *after* there's, and that we are confident.
>Yes and link to the Wiki's discredited list; linking to it. I'll get on that.
>
>~ David Smiley
>Apache Lucene/Solr Search Developer
>http://www.linkedin.com/in/davidwsmiley<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidwsmiley&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662941393%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Rki1uzTNZgZf3exD4bPIslkV%2ByZFNq9vIUuYYevdzpQ%3D&reserved=0>
>
>
>On Sun, Dec 19, 2021 at 4:26 PM David Smiley <ds...@apache.org>> wrote:
>I like the idea of using our Wiki more as you describe. Not so much *new* news entries because I think search-ability of these CVEs is fine to an existing entry.
>
>~ David Smiley
>Apache Lucene/Solr Search Developer
>http://www.linkedin.com/in/davidwsmiley<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidwsmiley&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662951346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MVgMhMo9u1r%2BRsl15AhJ3CKv%2FoFSbfsRgSJsYxzgU9g%3D&reserved=0>
>
>
>On Sat, Dec 18, 2021 at 4:39 PM Gus Heck <gu...@gmail.com>> wrote:
>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 <gu...@gmail.com>> 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FSOLR%2FSolrSecurity%23SolrSecurity-SolrandVulnerabilityScanningTools&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662951346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=I6rbMyvyzzJBdjL73ifB75baXJdAPw1evm0L2qUbpdw%3D&reserved=0>. 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 <ja...@cominvent.com>> 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fsolr-site%2Fcommits%2Fe10a6a9fe0eed8dcba3ad1a076c8208e014e76ff%2Fcontent%2Fsolr%2Fsecurity%2F2021-12-10-cve-2021-44228.md&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662961300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nz2UU9Ad64vUm%2BEQqIhXQ2GUt1u8lm16ejuow%2Fn9kmc%3D&reserved=0>
>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 <uw...@thetaphi.de>>:
>
>Hi all, I prepared a PR about the followup CVE-2021-45046: https://github.com/apache/solr-site/pull/59<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fsolr-site%2Fpull%2F59&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662961300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IReCUhmvtj1S6LmCNODHkb5L643m43UOTnbXAkjSK5M%3D&reserved=0>
>
>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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thetaphi.de%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662971256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=quNfHhhrhHzvD9Ci5TiWY6QjjKQpWsBuJ8wXRGCrGNI%3D&reserved=0>
>eMail: uwe@thetaphi.de<ma...@thetaphi.de>
>
>From: Uwe Schindler <uw...@thetaphi.de>>
>Sent: Wednesday, December 15, 2021 3:31 PM
>To: 'dev@lucene.apache.org<ma...@lucene.apache.org>' <de...@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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thetaphi.de%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662971256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=quNfHhhrhHzvD9Ci5TiWY6QjjKQpWsBuJ8wXRGCrGNI%3D&reserved=0>
>eMail: uwe@thetaphi.de<ma...@thetaphi.de>
>
>From: Gus Heck <gu...@gmail.com>>
>Sent: Wednesday, December 15, 2021 12:39 AM
>To: dev <de...@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 <uw...@thetaphi.de>> 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 <uw...@thetaphi.de>>:
>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 <fr...@rodland.no>>:
>
>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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogging.apache.org%2Flog4j%2F2.x%2Fsecurity.html&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662981218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YXNmtj22AynbWY%2Fr9dyG43zmysUKLenRjGc8555K7Ys%3D&reserved=0>
>"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 1 Twitter: @fredrikr
>NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.flickr.com%2Ffmmr%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662991168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sRnPGLpuHPV6Rrr%2FAcAsNUpYwcXKRIblSMWQdpoAPO4%3D&reserved=0>
>http://rodland.no<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Frodland.no%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662991168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n3RE9rfwanWAgf6kk36vYjK866%2Bwx0msPAAQMhzqjo8%3D&reserved=0> about.me<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663001126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZJKzt%2BKSN9fWKo7FbeHloxmhMtR8YTG0pou%2BU9ilyec%3D&reserved=0> http://about.me/fmr<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Ffmr&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663001126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JIibeFfBYOmfmIRLtv4AglnVgEz%2FkRDzW6P7fc%2FDmyE%3D&reserved=0>
>
>On 14 Dec 2021, at 23:44, Mike Drob <md...@mdrob.com>> 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 <fr...@rodland.no>> wrote:
>Only setting -Dlog4j2.formatMsgNoLookups=true might not be enough to mitigate the log4j vulnerability.
>
>See https://github.com/kmindi/log4shell-vulnerable-app<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkmindi%2Flog4shell-vulnerable-app&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663011082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AnlTYlZNKaKT5xMkiqPiRnUWvjFVV5KaXCL7nDYIv0I%3D&reserved=0>
>“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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsolr.apache.org%2Fsecurity.html%23apache-solr-affected-by-apache-log4j-cve-2021-44228&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663021035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ed13hwV6Gou9zmOAP1iVBlHLT4WwCV3CVoTx7ZxO%2Bfs%3D&reserved=0>
>
>And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>
>
>
>Regards,
>
>
>Fredrik
>
>
>--
>Fredrik Rødland Cell: +47 99 21 98 17
>Maisen Pedersens vei 1 Twitter: @fredrikr
>NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.flickr.com%2Ffmmr%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663021035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Pr5DrP4OfphCRAYmbkZMNkkmZSoLFMOGaokBkkr05ms%3D&reserved=0>
>http://rodland.no<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Frodland.no%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663030995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=V06kjXBC0tUpXUi7T1o7e2MAvE16b2srGgNULtE627w%3D&reserved=0> about.me<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663030995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g%2B7Bn3KjwMRf%2FpE71B7TypgTAdxVSaiHf%2BIucCxAoQI%3D&reserved=0> http://about.me/fmr<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Ffmr&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663040953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9xOWi0BjQegHWm2B%2FDrHQ58l3eLllR43fAE1aUm1wDg%3D&reserved=0>
>
>________________________________
>
>To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org<ma...@lucene.apache.org>
>For additional commands, e-mail: dev-help@lucene.apache.org<ma...@lucene.apache.org>
>
>________________________________
>
>To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org<ma...@lucene.apache.org>
>For additional commands, e-mail: dev-help@lucene.apache.org<ma...@lucene.apache.org>
>--
>Uwe Schindler
>Achterdiek 19, 28357 Bremen
>https://www.thetaphi.de<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thetaphi.de%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663040953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=d%2B4q2DczBkIa9S7ectJOUbf9zhRaReiX5BcUFq3CXew%3D&reserved=0>
>--
>Uwe Schindler
>Achterdiek 19, 28357 Bremen
>https://www.thetaphi.de<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thetaphi.de%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663050906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4NQ1r0rMgmp7EBAWryngeF5Q9YLnnoo0os%2FU3%2BPsyNA%3D&reserved=0>
>
>
>--
>http://www.needhamsoftware.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.needhamsoftware.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663060859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IamfDqrescj972dFFjUeTjtSydxNzimue3HVyRTcF0w%3D&reserved=0> (work)
>http://www.the111shift.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.the111shift.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663060859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=27m8sD1HxOWr4qhIK5VBO9t4%2Fz55VmAYoQo6odT1VXU%3D&reserved=0> (play)
>
>
>
>--
>http://www.needhamsoftware.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.needhamsoftware.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663070819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tFM5eylq2Mi2XaT6PG93K0jdCWHXo682nnhC92syTR4%3D&reserved=0> (work)
>http://www.the111shift.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.the111shift.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663080780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rYXOPJUba7sx125n7qRfTAAG2EymFgaKgcwj5RYS3Qc%3D&reserved=0> (play)
>
>
>--
>http://www.needhamsoftware.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.needhamsoftware.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663080780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SGqH3WX54bpAbSUIgzlvP39lUoumXRRu02UjAyVp1DE%3D&reserved=0> (work)
>http://www.the111shift.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.the111shift.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663090728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Vy0lTDzPZPDisU74jcRb9Ppch0E3CfzOqPC4GzVHitU%3D&reserved=0> (play)
>
>
>--
>http://www.needhamsoftware.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.needhamsoftware.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663090728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ymIDtUy%2FhO7OnMvyhqM46%2BwiO2c38uvUypsaX82zEDQ%3D&reserved=0> (work)
>http://www.the111shift.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.the111shift.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663100691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UIW6h%2F94S4yxnJXiNGpvH6iNajMZ1GOOB7Xu8yZ8HlU%3D&reserved=0> (play)
--
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
Posted by Michael Schumann <sc...@adobe.com.INVALID>.
That is the case here at Adobe. Even though we have multiple mitigations in place for Solr (configuration, Java 11), we will be required to upgrade to Log4J version 2.17.
From: Gus Heck <gu...@gmail.com>
Reply-To: "dev@solr.apache.org" <de...@solr.apache.org>
Date: Tuesday, December 21, 2021 at 1:21 PM
To: "dev@solr.apache.org" <de...@solr.apache.org>
Subject: Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
For what it's worth, I'm seeing IT depts not wanting to track exceptions to the rule (such as solr) and requiring the library upgrades period.
On Tue, Dec 21, 2021 at 1:48 PM David Smiley <ds...@apache.org>> wrote:
(switching to dev@solr.apache.org<ma...@solr.apache.org>; the O.P. unfortunatelysent this to Lucene)
BTW I'm having a good conversation[1] with Ralph Goers on the Log4j2 PMC about the efficacy of log4j2.formatMsgNoLookups. So far I've learned nothing that concerns me and I feel better in fact about other apps using this mitigation.
[1]: https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fkgh63sncrsm2bls884pg87mnt8vqztmz&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662931434%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8V9PGM%2B6wzpqrE9hHt5W3CsZrej%2FTTD%2Ba0gjEz63yZU%3D&reserved=0>
I think we should update our security news to reference this conversation for those that want to dig deeper as evidence. The fact that Log4j's security page refers to this technique as "discredited" puts us in a position where we have to acknowledge this word on their part and defend ourselves so it's clear our guidance came out *after* there's, and that we are confident.
Yes and link to the Wiki's discredited list; linking to it. I'll get on that.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidwsmiley&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662941393%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Rki1uzTNZgZf3exD4bPIslkV%2ByZFNq9vIUuYYevdzpQ%3D&reserved=0>
On Sun, Dec 19, 2021 at 4:26 PM David Smiley <ds...@apache.org>> wrote:
I like the idea of using our Wiki more as you describe. Not so much *new* news entries because I think search-ability of these CVEs is fine to an existing entry.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidwsmiley&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662951346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MVgMhMo9u1r%2BRsl15AhJ3CKv%2FoFSbfsRgSJsYxzgU9g%3D&reserved=0>
On Sat, Dec 18, 2021 at 4:39 PM Gus Heck <gu...@gmail.com>> wrote:
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 <gu...@gmail.com>> 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FSOLR%2FSolrSecurity%23SolrSecurity-SolrandVulnerabilityScanningTools&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662951346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=I6rbMyvyzzJBdjL73ifB75baXJdAPw1evm0L2qUbpdw%3D&reserved=0>. 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 <ja...@cominvent.com>> 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fsolr-site%2Fcommits%2Fe10a6a9fe0eed8dcba3ad1a076c8208e014e76ff%2Fcontent%2Fsolr%2Fsecurity%2F2021-12-10-cve-2021-44228.md&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662961300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nz2UU9Ad64vUm%2BEQqIhXQ2GUt1u8lm16ejuow%2Fn9kmc%3D&reserved=0>
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 <uw...@thetaphi.de>>:
Hi all, I prepared a PR about the followup CVE-2021-45046: https://github.com/apache/solr-site/pull/59<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fsolr-site%2Fpull%2F59&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662961300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IReCUhmvtj1S6LmCNODHkb5L643m43UOTnbXAkjSK5M%3D&reserved=0>
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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thetaphi.de%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662971256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=quNfHhhrhHzvD9Ci5TiWY6QjjKQpWsBuJ8wXRGCrGNI%3D&reserved=0>
eMail: uwe@thetaphi.de<ma...@thetaphi.de>
From: Uwe Schindler <uw...@thetaphi.de>>
Sent: Wednesday, December 15, 2021 3:31 PM
To: 'dev@lucene.apache.org<ma...@lucene.apache.org>' <de...@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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thetaphi.de%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662971256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=quNfHhhrhHzvD9Ci5TiWY6QjjKQpWsBuJ8wXRGCrGNI%3D&reserved=0>
eMail: uwe@thetaphi.de<ma...@thetaphi.de>
From: Gus Heck <gu...@gmail.com>>
Sent: Wednesday, December 15, 2021 12:39 AM
To: dev <de...@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 <uw...@thetaphi.de>> 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 <uw...@thetaphi.de>>:
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 <fr...@rodland.no>>:
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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogging.apache.org%2Flog4j%2F2.x%2Fsecurity.html&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662981218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YXNmtj22AynbWY%2Fr9dyG43zmysUKLenRjGc8555K7Ys%3D&reserved=0>
"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 1 Twitter: @fredrikr
NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.flickr.com%2Ffmmr%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662991168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sRnPGLpuHPV6Rrr%2FAcAsNUpYwcXKRIblSMWQdpoAPO4%3D&reserved=0>
http://rodland.no<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Frodland.no%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184662991168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n3RE9rfwanWAgf6kk36vYjK866%2Bwx0msPAAQMhzqjo8%3D&reserved=0> about.me<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663001126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZJKzt%2BKSN9fWKo7FbeHloxmhMtR8YTG0pou%2BU9ilyec%3D&reserved=0> http://about.me/fmr<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Ffmr&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663001126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JIibeFfBYOmfmIRLtv4AglnVgEz%2FkRDzW6P7fc%2FDmyE%3D&reserved=0>
On 14 Dec 2021, at 23:44, Mike Drob <md...@mdrob.com>> 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 <fr...@rodland.no>> wrote:
Only setting -Dlog4j2.formatMsgNoLookups=true might not be enough to mitigate the log4j vulnerability.
See https://github.com/kmindi/log4shell-vulnerable-app<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkmindi%2Flog4shell-vulnerable-app&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663011082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AnlTYlZNKaKT5xMkiqPiRnUWvjFVV5KaXCL7nDYIv0I%3D&reserved=0>
“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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsolr.apache.org%2Fsecurity.html%23apache-solr-affected-by-apache-log4j-cve-2021-44228&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663021035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ed13hwV6Gou9zmOAP1iVBlHLT4WwCV3CVoTx7ZxO%2Bfs%3D&reserved=0>
And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
Regards,
Fredrik
--
Fredrik Rødland Cell: +47 99 21 98 17
Maisen Pedersens vei 1 Twitter: @fredrikr
NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.flickr.com%2Ffmmr%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663021035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Pr5DrP4OfphCRAYmbkZMNkkmZSoLFMOGaokBkkr05ms%3D&reserved=0>
http://rodland.no<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Frodland.no%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663030995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=V06kjXBC0tUpXUi7T1o7e2MAvE16b2srGgNULtE627w%3D&reserved=0> about.me<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663030995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g%2B7Bn3KjwMRf%2FpE71B7TypgTAdxVSaiHf%2BIucCxAoQI%3D&reserved=0> http://about.me/fmr<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Ffmr&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663040953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9xOWi0BjQegHWm2B%2FDrHQ58l3eLllR43fAE1aUm1wDg%3D&reserved=0>
________________________________
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org<ma...@lucene.apache.org>
For additional commands, e-mail: dev-help@lucene.apache.org<ma...@lucene.apache.org>
________________________________
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org<ma...@lucene.apache.org>
For additional commands, e-mail: dev-help@lucene.apache.org<ma...@lucene.apache.org>
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thetaphi.de%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663040953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=d%2B4q2DczBkIa9S7ectJOUbf9zhRaReiX5BcUFq3CXew%3D&reserved=0>
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thetaphi.de%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663050906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4NQ1r0rMgmp7EBAWryngeF5Q9YLnnoo0os%2FU3%2BPsyNA%3D&reserved=0>
--
http://www.needhamsoftware.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.needhamsoftware.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663060859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IamfDqrescj972dFFjUeTjtSydxNzimue3HVyRTcF0w%3D&reserved=0> (work)
http://www.the111shift.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.the111shift.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663060859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=27m8sD1HxOWr4qhIK5VBO9t4%2Fz55VmAYoQo6odT1VXU%3D&reserved=0> (play)
--
http://www.needhamsoftware.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.needhamsoftware.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663070819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tFM5eylq2Mi2XaT6PG93K0jdCWHXo682nnhC92syTR4%3D&reserved=0> (work)
http://www.the111shift.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.the111shift.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663080780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rYXOPJUba7sx125n7qRfTAAG2EymFgaKgcwj5RYS3Qc%3D&reserved=0> (play)
--
http://www.needhamsoftware.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.needhamsoftware.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663080780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SGqH3WX54bpAbSUIgzlvP39lUoumXRRu02UjAyVp1DE%3D&reserved=0> (work)
http://www.the111shift.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.the111shift.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663090728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Vy0lTDzPZPDisU74jcRb9Ppch0E3CfzOqPC4GzVHitU%3D&reserved=0> (play)
--
http://www.needhamsoftware.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.needhamsoftware.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663090728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ymIDtUy%2FhO7OnMvyhqM46%2BwiO2c38uvUypsaX82zEDQ%3D&reserved=0> (work)
http://www.the111shift.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.the111shift.com%2F&data=04%7C01%7Cschumann%40adobe.com%7C8cd4113474d543d5ec8808d9c4c789fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637757184663100691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UIW6h%2F94S4yxnJXiNGpvH6iNajMZ1GOOB7Xu8yZ8HlU%3D&reserved=0> (play)
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Shawn Heisey <ap...@elyograg.org>.
On 12/21/21 2:18 PM, Gus Heck wrote:
> For what it's worth, I'm seeing IT depts not wanting to track
> exceptions to the rule (such as solr) and requiring the library
> upgrades period.
Earlier today I tried a jar upgrade from 2.11.0 to 2.17.0 on Solr
7.5.0. It was successful. I made sure that the admin UI logging tab
still worked, by asking Solr to do a query that returned an error response.
Just now, I tried the same with Solr 7.4.0, which includes log4j 2.11.0
just like 7.5.0 does. That worked too.
When this problem first surfaced, I upgraded log4j on my own install of
Solr 8.11.0 from 7.14.1 and it still works. I have seen a report from
someone saying that they upgraded from 2.13.0 and that also worked. I
don't recall the Solr version they had.
So nice that the log4j team has kept the API stable, so any vulnerable
Solr version can simply replace the log4j jars with a newer version and
know that they have fixed the problem.
Would there be any interest in a script to automate the upgrade
process? Would also need to see if there is a secure way to validate
file hashes.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Gus Heck <gu...@gmail.com>.
For what it's worth, I'm seeing IT depts not wanting to track exceptions to
the rule (such as solr) and requiring the library upgrades period.
On Tue, Dec 21, 2021 at 1:48 PM David Smiley <ds...@apache.org> wrote:
> (switching to dev@solr.apache.org; the O.P. unfortunatelysent this to
> Lucene)
>
> BTW I'm having a good conversation[1] with Ralph Goers on the Log4j2 PMC
> about the efficacy of log4j2.formatMsgNoLookups. So far I've learned
> nothing that concerns me and I feel better in fact about other apps using
> this mitigation.
> [1]: https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz
>
> I think we should update our security news to reference this conversation
> for those that want to dig deeper as evidence. The fact that Log4j's
> security page refers to this technique as "discredited" puts us in a
> position where we have to acknowledge this word on their part and defend
> ourselves so it's clear our guidance came out *after* there's, and that we
> are confident.
> Yes and link to the Wiki's discredited list; linking to it. I'll get on
> that.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Dec 19, 2021 at 4:26 PM David Smiley <ds...@apache.org> wrote:
>
>> I like the idea of using our Wiki more as you describe. Not so much
>> *new* news entries because I think search-ability of these CVEs is fine to
>> an existing entry.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sat, Dec 18, 2021 at 4:39 PM Gus Heck <gu...@gmail.com> wrote:
>>
>>> 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 <gu...@gmail.com> 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
>>>> <https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools>.
>>>> 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 <ja...@cominvent.com>
>>>> 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 <uw...@thetaphi.de>:
>>>>>
>>>>> 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: uwe@thetaphi.de
>>>>>
>>>>> *From:* Uwe Schindler <uw...@thetaphi.de>
>>>>> *Sent:* Wednesday, December 15, 2021 3:31 PM
>>>>> *To:* 'dev@lucene.apache.org' <de...@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: uwe@thetaphi.de
>>>>>
>>>>> *From:* Gus Heck <gu...@gmail.com>
>>>>> *Sent:* Wednesday, December 15, 2021 12:39 AM
>>>>> *To:* dev <de...@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 <uw...@thetaphi.de> 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 <
>>>>> uwe@thetaphi.de>:
>>>>>
>>>>> 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 <fr...@rodland.no>:
>>>>>
>>>>> 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 1 Twitter: @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 <md...@mdrob.com> 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 <fr...@rodland.no> 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>>>>>
>>>>> And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Fredrik
>>>>>
>>>>>
>>>>> --
>>>>> Fredrik Rødland Cell: +47 99 21 98 17
>>>>> Maisen Pedersens vei 1 Twitter: @fredrikr
>>>>> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
>>>>> http://rodland.no about.me http://about.me/fmr
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>> --
>>>>> Uwe Schindler
>>>>> Achterdiek 19, 28357 Bremen
>>>>> https://www.thetaphi.de
>>>>>
>>>>> --
>>>>> Uwe Schindler
>>>>> Achterdiek 19, 28357 Bremen
>>>>> https://www.thetaphi.de
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.needhamsoftware.com (work)
>>>>> http://www.the111shift.com (play)
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> http://www.needhamsoftware.com (work)
>>>> http://www.the111shift.com (play)
>>>>
>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by David Smiley <ds...@apache.org>.
(switching to dev@solr.apache.org; the O.P. unfortunatelysent this to
Lucene)
BTW I'm having a good conversation[1] with Ralph Goers on the Log4j2 PMC
about the efficacy of log4j2.formatMsgNoLookups. So far I've learned
nothing that concerns me and I feel better in fact about other apps using
this mitigation.
[1]: https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz
I think we should update our security news to reference this conversation
for those that want to dig deeper as evidence. The fact that Log4j's
security page refers to this technique as "discredited" puts us in a
position where we have to acknowledge this word on their part and defend
ourselves so it's clear our guidance came out *after* there's, and that we
are confident.
Yes and link to the Wiki's discredited list; linking to it. I'll get on
that.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Sun, Dec 19, 2021 at 4:26 PM David Smiley <ds...@apache.org> wrote:
> I like the idea of using our Wiki more as you describe. Not so much
> *new* news entries because I think search-ability of these CVEs is fine to
> an existing entry.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sat, Dec 18, 2021 at 4:39 PM Gus Heck <gu...@gmail.com> wrote:
>
>> 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 <gu...@gmail.com> 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
>>> <https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools>.
>>> 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 <ja...@cominvent.com>
>>> 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 <uw...@thetaphi.de>:
>>>>
>>>> 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: uwe@thetaphi.de
>>>>
>>>> *From:* Uwe Schindler <uw...@thetaphi.de>
>>>> *Sent:* Wednesday, December 15, 2021 3:31 PM
>>>> *To:* 'dev@lucene.apache.org' <de...@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: uwe@thetaphi.de
>>>>
>>>> *From:* Gus Heck <gu...@gmail.com>
>>>> *Sent:* Wednesday, December 15, 2021 12:39 AM
>>>> *To:* dev <de...@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 <uw...@thetaphi.de> 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 <
>>>> uwe@thetaphi.de>:
>>>>
>>>> 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 <fr...@rodland.no>:
>>>>
>>>> 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 1 Twitter: @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 <md...@mdrob.com> 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 <fr...@rodland.no> 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>>>>
>>>> And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Fredrik
>>>>
>>>>
>>>> --
>>>> Fredrik Rødland Cell: +47 99 21 98 17
>>>> Maisen Pedersens vei 1 Twitter: @fredrikr
>>>> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
>>>> http://rodland.no about.me http://about.me/fmr
>>>>
>>>> ------------------------------
>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>> ------------------------------
>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>> --
>>>> Uwe Schindler
>>>> Achterdiek 19, 28357 Bremen
>>>> https://www.thetaphi.de
>>>>
>>>> --
>>>> Uwe Schindler
>>>> Achterdiek 19, 28357 Bremen
>>>> https://www.thetaphi.de
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.needhamsoftware.com (work)
>>>> http://www.the111shift.com (play)
>>>>
>>>>
>>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by David Smiley <ds...@apache.org>.
I like the idea of using our Wiki more as you describe. Not so much
*new* news entries because I think search-ability of these CVEs is fine to
an existing entry.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Sat, Dec 18, 2021 at 4:39 PM Gus Heck <gu...@gmail.com> wrote:
> 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 <gu...@gmail.com> 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
>> <https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools>.
>> 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 <ja...@cominvent.com>
>> 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 <uw...@thetaphi.de>:
>>>
>>> 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: uwe@thetaphi.de
>>>
>>> *From:* Uwe Schindler <uw...@thetaphi.de>
>>> *Sent:* Wednesday, December 15, 2021 3:31 PM
>>> *To:* 'dev@lucene.apache.org' <de...@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: uwe@thetaphi.de
>>>
>>> *From:* Gus Heck <gu...@gmail.com>
>>> *Sent:* Wednesday, December 15, 2021 12:39 AM
>>> *To:* dev <de...@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 <uw...@thetaphi.de> 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 <uwe@thetaphi.de
>>> >:
>>>
>>> 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 <fr...@rodland.no>:
>>>
>>> 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 1 Twitter: @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 <md...@mdrob.com> 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 <fr...@rodland.no> 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>>>
>>> And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>> Fredrik
>>>
>>>
>>> --
>>> Fredrik Rødland Cell: +47 99 21 98 17
>>> Maisen Pedersens vei 1 Twitter: @fredrikr
>>> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
>>> http://rodland.no about.me http://about.me/fmr
>>>
>>> ------------------------------
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>> ------------------------------
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de
>>>
>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de
>>>
>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>>
>>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Gus Heck <gu...@gmail.com>.
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 <gu...@gmail.com> 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
> <https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools>.
> 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 <ja...@cominvent.com>
> 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 <uw...@thetaphi.de>:
>>
>> 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: uwe@thetaphi.de
>>
>> *From:* Uwe Schindler <uw...@thetaphi.de>
>> *Sent:* Wednesday, December 15, 2021 3:31 PM
>> *To:* 'dev@lucene.apache.org' <de...@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: uwe@thetaphi.de
>>
>> *From:* Gus Heck <gu...@gmail.com>
>> *Sent:* Wednesday, December 15, 2021 12:39 AM
>> *To:* dev <de...@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 <uw...@thetaphi.de> 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 <uwe@thetaphi.de
>> >:
>>
>> 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 <fr...@rodland.no>:
>>
>> 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 1 Twitter: @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 <md...@mdrob.com> 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 <fr...@rodland.no> 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>>
>> And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>>
>>
>>
>> Regards,
>>
>>
>> Fredrik
>>
>>
>> --
>> Fredrik Rødland Cell: +47 99 21 98 17
>> Maisen Pedersens vei 1 Twitter: @fredrikr
>> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
>> http://rodland.no about.me http://about.me/fmr
>>
>> ------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> ------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>>
>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Gus Heck <gu...@gmail.com>.
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
<https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools>.
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 <ja...@cominvent.com> 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 <uw...@thetaphi.de>:
>
> 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: uwe@thetaphi.de
>
> *From:* Uwe Schindler <uw...@thetaphi.de>
> *Sent:* Wednesday, December 15, 2021 3:31 PM
> *To:* 'dev@lucene.apache.org' <de...@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: uwe@thetaphi.de
>
> *From:* Gus Heck <gu...@gmail.com>
> *Sent:* Wednesday, December 15, 2021 12:39 AM
> *To:* dev <de...@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 <uw...@thetaphi.de> 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 <uw...@thetaphi.de>:
>
> 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 <fr...@rodland.no>:
>
> 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 1 Twitter: @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 <md...@mdrob.com> 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 <fr...@rodland.no> 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>
> And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>
>
>
> Regards,
>
>
> Fredrik
>
>
> --
> Fredrik Rødland Cell: +47 99 21 98 17
> Maisen Pedersens vei 1 Twitter: @fredrikr
> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
> http://rodland.no about.me http://about.me/fmr
>
> ------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> ------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
>
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <uw...@thetaphi.de>:
>
> Hi all, I prepared a PR about the followup CVE-2021-45046: https://github.com/apache/solr-site/pull/59 <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 <https://www.thetaphi.de/>
> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>
> From: Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>>
> Sent: Wednesday, December 15, 2021 3:31 PM
> To: 'dev@lucene.apache.org <ma...@lucene.apache.org>' <dev@lucene.apache.org <ma...@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 <https://www.thetaphi.de/>
> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>
> From: Gus Heck <gus.heck@gmail.com <ma...@gmail.com>>
> Sent: Wednesday, December 15, 2021 12:39 AM
> To: dev <dev@lucene.apache.org <ma...@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 <uwe@thetaphi.de <ma...@thetaphi.de>> 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 <uwe@thetaphi.de <ma...@thetaphi.de>>:
>>> 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 <fredrik@rodland.no <ma...@rodland.no>>:
>>>> 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 <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 1 Twitter: @fredrikr
>>>> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/ <http://www.flickr.com/fmmr/>
>>>> http://rodland.no <http://rodland.no/> about.me <http://about.me/> http://about.me/fmr <http://about.me/fmr>
>>>>
>>>>> On 14 Dec 2021, at 23:44, Mike Drob <mdrob@mdrob.com <ma...@mdrob.com>> 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 <fredrik@rodland.no <ma...@rodland.no>> wrote:
>>>>> Only setting -Dlog4j2.formatMsgNoLookups=true might not be enough to mitigate the log4j vulnerability.
>>>>>
>>>>> See https://github.com/kmindi/log4shell-vulnerable-app <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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228 <https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228>
>>>>>
>>>>> And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Fredrik
>>>>>
>>>>>
>>>>> --
>>>>> Fredrik Rødland Cell: +47 99 21 98 17
>>>>> Maisen Pedersens vei 1 Twitter: @fredrikr
>>>>> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/ <http://www.flickr.com/fmmr/>
>>>>> http://rodland.no <http://rodland.no/> about.me <http://about.me/> http://about.me/fmr <http://about.me/fmr>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de <https://www.thetaphi.de/>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de <https://www.thetaphi.de/>
>
>
> --
> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work)
> http://www.the111shift.com <http://www.the111shift.com/> (play)
RE: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
From: Uwe Schindler <uw...@thetaphi.de>
Sent: Wednesday, December 15, 2021 3:31 PM
To: 'dev@lucene.apache.org' <de...@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: uwe@thetaphi.de <ma...@thetaphi.de>
From: Gus Heck <gus.heck@gmail.com <ma...@gmail.com> >
Sent: Wednesday, December 15, 2021 12:39 AM
To: dev <dev@lucene.apache.org <ma...@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 <uwe@thetaphi.de <ma...@thetaphi.de> > 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 <uwe@thetaphi.de <ma...@thetaphi.de> >:
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 <fredrik@rodland.no <ma...@rodland.no> >:
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 1 Twitter: @fredrikr
NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
http://rodland.no about.me <http://about.me> http://about.me/fmr
On 14 Dec 2021, at 23:44, Mike Drob <mdrob@mdrob.com <ma...@mdrob.com> > 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 <fredrik@rodland.no <ma...@rodland.no> > 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
Regards,
Fredrik
--
Fredrik Rødland Cell: +47 99 21 98 17
Maisen Pedersens vei 1 Twitter: @fredrikr
NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
http://rodland.no about.me <http://about.me> http://about.me/fmr
_____
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
_____
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Gus Heck <gu...@gmail.com>.
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 <uw...@thetaphi.de> 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 <uw...@thetaphi.de>:
>>
>> 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 <fr...@rodland.no>:
>>>
>>> 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 1 Twitter: @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 <md...@mdrob.com> 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 <fr...@rodland.no> 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>>>>
>>>> And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Fredrik
>>>>
>>>>
>>>> --
>>>> Fredrik Rødland Cell: +47 99 21 98 17
>>>> Maisen Pedersens vei 1 Twitter: @fredrikr
>>>> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
>>>> http://rodland.no about.me http://about.me/fmr
>>>> ------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>> ------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Uwe Schindler <uw...@thetaphi.de>.
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 <uw...@thetaphi.de>:
>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 <fr...@rodland.no>:
>>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 1 Twitter: @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 <md...@mdrob.com> 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 <fr...@rodland.no> 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>>>
>>> And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>> Fredrik
>>>
>>>
>>> --
>>> Fredrik Rødland Cell: +47 99 21 98 17
>>> Maisen Pedersens vei 1 Twitter: @fredrikr
>>> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
>>> http://rodland.no about.me http://about.me/fmr
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>--
>Uwe Schindler
>Achterdiek 19, 28357 Bremen
>https://www.thetaphi.de
--
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
Posted by Uwe Schindler <uw...@thetaphi.de>.
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 <fr...@rodland.no>:
>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 1 Twitter: @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 <md...@mdrob.com> 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 <fr...@rodland.no> 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>>
>> And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>>
>>
>>
>> Regards,
>>
>>
>> Fredrik
>>
>>
>> --
>> Fredrik Rødland Cell: +47 99 21 98 17
>> Maisen Pedersens vei 1 Twitter: @fredrikr
>> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
>> http://rodland.no about.me http://about.me/fmr
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>For additional commands, e-mail: dev-help@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
Posted by solr <fr...@rodland.no>.
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 1 Twitter: @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 <md...@mdrob.com> 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 <fr...@rodland.no> 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>
> And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>
>
>
> Regards,
>
>
> Fredrik
>
>
> --
> Fredrik Rødland Cell: +47 99 21 98 17
> Maisen Pedersens vei 1 Twitter: @fredrikr
> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
> http://rodland.no about.me http://about.me/fmr
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by solr <fr...@rodland.no>.
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 1 Twitter: @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 <md...@mdrob.com> 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 <fr...@rodland.no> 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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>
> And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>
>
>
> Regards,
>
>
> Fredrik
>
>
> --
> Fredrik Rødland Cell: +47 99 21 98 17
> Maisen Pedersens vei 1 Twitter: @fredrikr
> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
> http://rodland.no about.me http://about.me/fmr
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Mike Drob <md...@mdrob.com>.
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 <fr...@rodland.no> 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:
> https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>
> And maybe consider releasing patch releases for other versions than 8.11
> as well which includes log4j 2.16.0?
>
>
>
> Regards,
>
>
> Fredrik
>
>
> --
> Fredrik Rødland Cell: +47 99 21 98 17
> Maisen Pedersens vei 1 Twitter: @fredrikr
> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
> http://rodland.no about.me http://about.me/fmr
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
Solr does use MDC (the %X pattern), but the values are not user generated and all come from config files and are enforced to comply to certain formats (e.g., no $ possible). Shard, replica, collection names are sanitized.
In short all fine, no need to change the mitigation instructions. There is also no need to update log4j in older versions of Solr.
Uwe
Am 14. Dezember 2021 21:10:26 UTC schrieb solr <fr...@rodland.no>:
>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: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>
>And maybe consider releasing patch releases for other versions than 8.11 as well which includes log4j 2.16.0?
>
>
>
>Regards,
>
>
>Fredrik
>
>
>--
>Fredrik Rødland Cell: +47 99 21 98 17
>Maisen Pedersens vei 1 Twitter: @fredrikr
>NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
>http://rodland.no about.me http://about.me/fmr
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>For additional commands, e-mail: dev-help@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
Posted by Mike Drob <md...@mdrob.com>.
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 <fr...@rodland.no> 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:
> https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
>
> And maybe consider releasing patch releases for other versions than 8.11
> as well which includes log4j 2.16.0?
>
>
>
> Regards,
>
>
> Fredrik
>
>
> --
> Fredrik Rødland Cell: +47 99 21 98 17
> Maisen Pedersens vei 1 Twitter: @fredrikr
> NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
> http://rodland.no about.me http://about.me/fmr
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>