The hunt for the vulnerabilities of Log4j is proving to be particularly complex


Free software is ubiquitous today, but the Log4j flaw, which affects enterprise Java applications, is a reminder of what can go wrong in the complex supply chain of modern software.

The issue with the flaw that affects Log4j (also known as Log4Shell) is not just that administrators need to fix this flaw, which has been rated as “critical” of 10 out of 10. The real difficulty lies in the fact that users cannot know whether a product or system is affected by the component’s vulnerability.

Google calculated that approximately 17,000 Java packages in the Maven Central repository – the largest Java package repository – contained the vulnerable log4j-core library as a direct or transitive dependency.

And now security company JFrog has found more by identifying additional packages containing the Log4j vulnerability that would not have been detected by the dependency scan – that is, packages containing vulnerable Log4j code in the artifact itself.

He found that, overall, directly including Log4j code in artifacts is not as common as using Log4j through dependencies. However, this still represents hundreds of packages – around 400 – that directly include Log4j code, exposing these packages to the vulnerabilities of Log4j.

“In more than half of the cases (~ 65%), Log4j code is included directly as classes (ie direct inclusion / shading), unlike the inclusion of full Log4j .jar files, which is typically how it is presented in the rest of the cases. These numbers indicate that tools that only search for full .jar files will miss out on most cases where Log4j is included directly, ”he said.

This bug reminds us why Microsoft and Google are investing in projects to strengthen the security of open source software projects, which are the backbone of today’s internet infrastructure. Previous research shows that the vast majority of software vulnerabilities are found in software libraries or dependencies.

The severity of the bug means that administrators have a vested interest in examining any Java applications that may include Log4j code. Microsoft has released scan tools to detect vulnerable Windows and Linux systems, vulnerable applications and devices, and JFrog offers an additional option.

JFrog emphasizes that its analysis targets complementary code rather than simply detecting the presence of a version of the software library.

“The reason why parsing the full list of dependencies may miss instances of the included Log4j code is that the dependencies only specify the external packages needed to build or run the current artifact. If the vulnerable code is inserted directly into the code base, it is not a dependency. Therefore, for more accurate detection of vulnerable Log4j code, we need to inspect the code itself, ”the company said in a blog post.

This research highlights the vulnerability of today’s computer systems to attacks targeting the software supply chain.

The importance of the Java programming language should not be underestimated. It remains one of the most widely used languages ​​in the world and is the reference language for businesses. Its ecosystem includes projects such as Microsoft’s implementation of OpenJDK. Microsoft uses Java in Azure, SQL Server, Yammer, Minecraft, and LinkedIn.

Source: ZDNet.com;





Source link -97