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.