Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

Log4j RCE: Emergency patch issued to plug critical auth-free code execution hole in widely used logging utility

Prepare to have a very busy weekend of mitigating and patching

Updated An unauthenticated remote code execution vulnerability in Apache's Log4j Java-based logging tool is being actively exploited, researchers have warned after it was used to execute code on Minecraft servers.

Infosec firm Randori summarised the vuln in a blog post, saying: "Effectively, any scenario that allows a remote connection to supply arbitrary data that is written to log files by an application utilizing the Log4j library is susceptible to exploitation."

Crafted proof-of-concept code snippets are already doing the rounds.

The vuln is being tracked as CVE-2021-44228 and affects versions of Log4j before 2.14.1. Proof-of-concept code was posted to GitHub by a member of the Alibaba Cloud security team, along with a brief readme (in Chinese) saying: "After verification by the Alibaba Cloud security team, Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc. are all affected."

The Apache Foundation published a patch for the critical-rated vuln earlier today. Its patch notes confirmed: "An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled."

We have contacted Apache for comment and will update this article when it responds. It seems that the root cause of the problem is that Log4j was parsing certain code snippets in user input. Whether it was or not, it affects both Log4j and its newer version, Log4j2.

Infosec outfit Lunasec has a detailed blog post about the flaw.

Immersive Labs' application security specialist Sean Wright told The Register that while immediate patches are available, it may be better to mitigate now and wait for a stable candidate.

"My advice to organizations is to look to the temporary remedial advice (setting the formatMsgNoLookups=true property) and wait for the patched versions to become available," he said. "While there are release candidates for the patches, they are not stable releases and can carry their own risks, so apply the temporary remediation until you can apply the patch from a stable version."

Marcus Hutchins, the infosec bod who stopped the WannaCry attack against Britain's NHS a few years ago, described it as "extremely bad."

Jamie Moles, a senior technical manager at network detection and response firm ExtraHop, told El Reg the RCE is likely to affect "many cloud platforms including Steam, iCloud and Minecraft."

"The problem is mitigated by patching," he continued. "Updating the log4j-core.jar to version 2.15.0, which was released today, fixes the problem. But we are now in December and many online services are going to be in a change freeze at this point in time – meaning the business won't tolerate downtime to patch the issue. It will be interesting if this is seen to propagate into retail."

Log4j is also the default logging utility in Elasticsearch, among many other products and services relied upon by enterprises. If you were hoping for an early finish this weekend, sorry: like time, vulns wait for no man. ®

Updated to add at 09:31 on 13 December 2021:

Ralph Goers, member of the Apache Logging Services Project Management Committee, told The Reg in a statement: "Many frameworks reference other frameworks and specify versions that they were built with. However, most framework (like Log4j) are designed to be backward-compatible.

"So although Apache Struts may depend on a specific version of Log4j when users create their applications they frequently change the versions to meet their requirements. So those frameworks are not at immediate risk but their users would be.

"Projects and vendors that deliver a fully packaged applications would be affected."

More about

TIP US OFF

Send us news


Other stories you might like