The challenge with the Log4j flaw (also known as Log4Shell) is not only that admins need to patch the flaw – which got a ‘critical’ rating of 10 out of 10 – but that IT folk can’t easily discover whether a product or system is affected by the vulnerability in the component. Google has calculated that approximately 17,000 Java packages in the Maven Central repository – the most significant Java package repository – were found to contain the vulnerable log4j-core library as a direct or transitive dependency. SEE: A winning strategy for cybersecurity (ZDNet special report) And now security firm JFrog has found more by identifying additional packages containing the Log4j vulnerability that would not be detected through dependency scanning – that is, packages containing vulnerable Log4j code within the artefact itself. JFrog found that direct inclusion of Log4j code in artefacts is not as common as the use of Log4j through dependencies. However, it still adds up to hundreds of packages – around 400 – that directly include Log4j code, opening these packages to Log4j vulnerabilities. “In more than half of all cases (~65%), Log4j code is included as classes directly (i.e. direct inclusion / shading), in contrast to including complete Log4j .jar files (i.e. fat jar), which is typically how it is presented in the remainder of cases. These numbers indicate that tools looking for complete .jar files only will miss most of the cases where Log4j is included directly,” it said. The bug is a reminder why Microsoft and Google are ploughing dollars into projects that bolster the security of open-source software projects, which are the backbone today’s internet infrastructure. Previous research shows that the vast majority of software flaws are found in software libraries or dependencies. The severity of the bug means admins could be well-served by investigating all Java applications that might include Log4j code. Microsoft has released scanning tools to detect vulnerable WIndows and Linux systems, applications and devices, and JFrog offers one more option. JFrog emphasizes its scanning reaches the add-on code rather than just the fact a version of the software library is present. “The reason that scanning the full dependencies list may miss instances of included Log4j code is because dependencies only specify external packages needed to build or run the current artefact. If the vulnerable code is inserted directly into the codebase, it is not a dependency. Therefore, for more precise detection of vulnerable Log4j code, we need to inspect the code itself,” the company notes in a blogpost. The research highlights how vulnerable today’s IT systems are to attacks on the software supply chain. The importance of the Java programming language can’t be underestimated. It remains one the world’s most widely used languages and is the go-to language for enterprise, and includes in its ecosystem projects like Microsoft’s implementation of OpenJDK. Microsoft uses Java in Azure, SQL Server, Yammer, Minecraft, and LinkedIn.
