Reader Comment – Another Log4Shell Advisory and Update

Early this morning (not so early in Israel) I had a reader DM me over on LinkedIn (FYI www.linkedin.com/in/patrickcoyle) about a couple of other vendor notifications about Log4Shell. One was one I had covered in an earlier post (but it was updated yesterday) and the other was new to me. So, I appreciate the information and will share it here. Oh, and this leads down an interesting rabbit hole.

Prosys OPC

Proxyx OPC published a blog post about the Log4Shell vulnerability. They do not have advisories, per se, they use their blogging function to also serve that purpose. In any case, while not as stylized as an advisory the post does provide listings of affected products, unaffected products, and available mitigation measures.

Siemens Update

Siemens published an update for their Log4Shell advisory that was originally published on December 12^th, 2021. The new information includes:

• Adding additional potentially affected products,

• Adding additional mitigation measures,

• Added CVE-2021-45046 (see discussion below), and

• Updated mitigation measures for new CVE.

Log4Shell2

Okay, the cute name is mine, but it looks like it may be appropriate. According to the NVD.NIST.gov entry for CVE-2021-45046: “It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.” Please see my TWEET® reply from yesterday morning.

According to the Apache Log4j Security Vulnerabilities page, this new vulnerability was reported to them by Kai Mindermann of iC Consult. That page also notes that:

“Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.

“The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors. [emphasis added]

“The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.”

Maybe we want to change the name to “Log4Hell”.