Thanks… That did find some additional packages hiding this scourge (about a dozen or so packages, around 100 packages removed after the dependency chains were resolved).
On Dec 14, 2021, at 09:30 , Tyler Conrad <tyler@tgconrad.com> wrote:
Another handy one to find where it's hiding, since it can be bundled inside other JARs: find / -name *.jar | xargs strings -f | grep -i log4j
If you’re on fedora, it can be useful to pipe the output of that to cut -f 1 -d : | xargs rpm -q —whatprovides which will give you the package names responsible for the files in question. One of the ones I discovered required quite a number of eclipse-* packages to be removed. Of the things that were found, there wasn’t anything I cared enough about keeping, so I’m still inclined to believe that rpm-e is the best solution to this problem at this point. Owen
On Tue, Dec 14, 2021 at 6:57 AM Doug McIntyre <merlyn@geeks.org <mailto:merlyn@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 <nick@foobar.org <mailto:nick@foobar.org>> wrote: ... https://logging.apache.org/log4j/2.x/security.html <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.