As the global response to the Log4Shell zero-day was starting to settle into the long game of “scan and patch” we were all thrown a (relatively small) curve ball yesterday.

As we discussed on Monday, the Apache Team was quick to release a fix (2.15.0) on Friday, 10th December. Unfortunately, it was announced yesterday that the fix was incomplete in certain non-default configurations. This is not uncommon with zero-day exploits, as vendors move fast to plug gaps – so we continue to monitor the Apache message boards closely.

As such, this is being treated as a new vulnerability – another CVE-ID has been opened, CVE-2021-45046 and Apache have released a new fix in the form of 2.16.0 (release notes here).

While it is limited to non-default configurations, it also negates a previous migration strategy, i.e.:

“Previous mitigations involving configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability.“

Therefore, current advice is to:

· Patch systems to v2.16.0.

OR

· Use the workaround by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Options have updated our Firewall IPS signatures and vulnerability scanners accordingly. We are applying v2.16.0 to any system that we patched to v2.15.0 and using v2.16.0 going forward.

We would also like to thank our clients for their continued support, flexibility, and advice. These significant zero-day exploits obviously cannot be planned and instantly become large non-trivial global projects, so their help and understanding have been invaluable! As ever, please feel free to get in contact with your Options contact to discuss today’s blog or any impact you may be having from the zero-day incident.

To learn more about Options Managed Security offering, click here.

• Options InfoSec Committee.