Log4j mitigation

Sat Dec 11 08:01:56 UTC 2021

Am 11.12.2021 um 04:54 schrieb Andy Ringsmuth <andy at andyring.com>:
> 
> The intricacies of Java are over my head, but I’ve been reading about this Log4j issue that sounds pretty bad.
> 
> What do we know about this? What, if anything, can a network operator do to help mitigate this? Or even an end user?

Probably not. The problem lies in the functionality of log4j to do token interpolation (think "foo ${bar} baz") not just on the format string that is configured, but also on the values passed into the logging function call.

Let that sit for a minute.

For most applications that receive input over the network, I would expect it's close to impossible to recognise problematic input that might be logged while processing the request, or even at a later stage. The URL is an obvious place, but form input, or even the contents of a ZIP file that is being uploaded might be processed by logging function calls.

The good news is that setting the Java system property log4j2.formatMsgNoLookups to true disables the vulnerable functionality. For most Java server applications, that should be a very quick change.

Stefan

--
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20211211/a6a92afb/attachment.sig>