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 <[email protected]> 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 <[email protected]>:
>>
>> 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 <[email protected]>:
>>>
>>> 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 <[email protected]> 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 <[email protected]> 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: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>> ------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>> --
>> 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)

Reply via email to