<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span style="font-size: 19px;" class="">Thanks… That did find some additional packages hiding this scourge (about a dozen or so packages,</span><div class=""><span style="font-size: 19px;" class="">around 100 packages removed after the dependency chains were resolved).</span></div><div class=""><span style="font-size: 19px;" class=""><br class=""></span><div class=""><div style="font-size: 19px;"><br class=""><blockquote type="cite" class=""><div class="">On Dec 14, 2021, at 09:30 , Tyler Conrad <<a href="mailto:tyler@tgconrad.com" class="">tyler@tgconrad.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Another handy one to find where it's hiding, since it can be bundled inside other JARs:<div class="">find / -name *.jar | xargs strings -f | grep -i log4j<br class=""></div></div></div></blockquote><div style="font-size: 19px;"><br class=""></div>If you’re on fedora, it can be useful to pipe the output of that to</div><div style="font-size: 19px;"><span class="Apple-tab-span" style="white-space:pre"> </span>cut -f 1 -d : | xargs rpm -q —whatprovides</div><div style="font-size: 19px;">which will give you the package names responsible for the files in question.</div><div style="font-size: 19px;"><br class=""></div><div style="font-size: 19px;">One of the ones I discovered required quite a number of eclipse-* packages to be removed.</div><div style="font-size: 19px;"><br class=""></div><div style="font-size: 19px;">Of the things that were found, there wasn’t anything I cared enough about keeping, so I’m</div><div style="font-size: 19px;">still inclined to believe that rpm-e is the best solution to this problem at this point.</div><div style="font-size: 19px;"><br class=""></div><div style="font-size: 19px;">Owen</div><div style="font-size: 19px;"><br class=""></div><div style="font-size: 19px;"><br class=""></div><div style="font-size: 19px;"><blockquote type="cite" class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 14, 2021 at 6:57 AM Doug McIntyre <<a href="mailto:merlyn@geeks.org" class="">merlyn@geeks.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Dec 13, 2021 at 11:38:04AM -0800, Owen DeLong via NANOG wrote:<br class="">
> > On Dec 11, 2021, at 04:11 , Nick Hilliard <<a href="mailto:nick@foobar.org" target="_blank" class="">nick@foobar.org</a>> wrote:<br class="">
...<br class="">
> > <a href="https://logging.apache.org/log4j/2.x/security.html" rel="noreferrer" target="_blank" class="">https://logging.apache.org/log4j/2.x/security.html</a><br class="">
> > <br class="">
> > 1. upgrade log4j to 2.15.0 and restart all java apps<br class="">
> > 2. start java with "-D log4j2.formatMsgNoLookups=true" (v2.10+ only)<br class="">
> > 3. start java with "LOG4J_FORMAT_MSG_NO_LOOKUPS=true" environment variable (v2.10+ only)<br class="">
> > 4. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class<br class="">
> > <br 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.<br class="">
> > <br class="">
> > Nick<br class="">
> <br class="">
> Alternatively, this incantation solved the problem on my linux server:<br class="">
> <br class="">
> rpm -e log4j12 ant-apache-log4j log4j<br class="">
<br class="">
<br class="">
There are many software setups that bundle their own log4j.jar without<br class="">
bothering to go through the OS package manager....<br class="">
<br class="">
$ rpm -qa | fgrep log4j<br class="">
$<br class="">
<br class="">
$ find / -name log4j*jar<br class="">
....system/log4j/log4j/log4j/1.2.17/log4j-1.2.17.jar<br class="">
<br class="">
(obviously an old system due to the commands used and version found,<br class="">
and nor will it get patches available because of vendor...).<br class="">
<br class="">
Sorta like playing whack-a-mole with jquery.js (another package with<br class="">
lots of security history that seems to be copied _everywhere_ without<br class="">
registring it with the OS package manager). <br class="">
<br class="">
So, the exercise becomes _finding_ the software that uses it, and then<br class="">
doing the configs that defang JNDI everywhere you find it.<br class="">
<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></div></body></html>