> On Dec 14, 2021, at 06:54 , Doug McIntyre <mer...@geeks.org> wrote:
>
> On Mon, Dec 13, 2021 at 11:38:04AM -0800, Owen DeLong via NANOG wrote:
>>> On Dec 11, 2021, at 04:11 , Nick Hilliard <n...@foobar.org> wrote:
> ...
>>> https://logging.apache.org/log4j/2.x/security.html
>>>
>>> 1. upgrade log4j to 2.15.0 and restart all java apps
>>> 2. start java with "-D log4j2.formatMsgNoLookups=true" (v2.10+ only)
>>> 3. start java with "LOG4J_FORMAT_MSG_NO_LOOKUPS=true" environment variable
>>> (v2.10+ only)
>>> 4. zip -q -d log4j-core-*.jar
>>> org/apache/logging/log4j/core/lookup/JndiLookup.class
>>>
>>> There's a lot of scanning going on at the moment, so if you have an exposed
>>> java instance running something which includes log4j2, you may already be
>>> compromised.
>>>
>>> Nick
>>
>> Alternatively, this incantation solved the problem on my linux server:
>>
>> rpm -e log4j12 ant-apache-log4j log4j
>
>
> There are many software setups that bundle their own log4j.jar without
> bothering to go through the OS package manager....
>
> $ rpm -qa | fgrep log4j
> $
>
> $ find / -name log4j*jar
> ....system/log4j/log4j/log4j/1.2.17/log4j-1.2.17.jar
>
> (obviously an old system due to the commands used and version found,
> and nor will it get patches available because of vendor...).
>
> Sorta like playing whack-a-mole with jquery.js (another package with
> lots of security history that seems to be copied _everywhere_ without
> registring it with the OS package manager).
>
> So, the exercise becomes _finding_ the software that uses it, and then
> doing the configs that defang JNDI everywhere you find it.
YMMV… Find didn’t find anything named log4j\*jar after I did my rpm -e.
Owen
