You've probably seen a lot of activity around a recently discovered vulnerability in Log4J, even in the mainstream media. Although that coverage might have been more about the potential risk for Minecraft users than the fact that it scored the maximum "10 CRITICAL" score by the NIST. (See here for the official CVE record).

For Osirium customers: the good news is that we don’t use this library in any of our products (PAM, PPA, PEM) - so no need to worry there.  Even though the Osirium products are not built on Java, we're still being extra cautious and running tools such as Tenable Nessus for an external scan and using github dependency scanning.

Andy Harris explores the Log4J issue
Andy Harris explains why Log4J is such a critical issue and how PAM is an important defence

As vulnerabilities go, this one is a doozy, with the full CVE risk rating of 10.  Essentially, given an application built with Log4j if you can provoke a custom log message you can execute arbitary code. It’s the arbitrary code which can be remotely driven with no authentication that gives it the 10 rating.  In security terms that’s the big three.

Log4j can expose some logging ports so external applications could be generating logged messages.  Right now, in the wild there seems to be some instances of mal-formed messages designed to get some applications crypto-mining on the attackers behalf.

If you have legacy applications that you cannot change, then Web Application Firewalls are probably your best route to initial protection. Of course, also keep checking all your network and software providers for any updates and advice on how to protect your systems.

If you have any questions, please get in touch.

Related Topics