Despite What Some Vendors Say, Please Don’t Ignore Log4j

Mirroring the explosive growth of open source software, analysis around open source vulnerabilities continues to dominate headlines. However, in an alarming trend, many security vendors have begun citing stats that downplay risk to amplify their services, like the recent statistic that “96% of Log4j in use…was not vulnerable to the Log4Shell zero-day.” At first glance this seems like a great result – now you only have to worry about fixing 4% of your applications! However, once you understand how such vulnerability analyses are performed and how exploitability progresses, the idea of having known vulnerable libraries included in your applications tends to become very uncomfortable. In fact, recommending that high-severity open source vulnerabilities be left in application code is more than irresponsible – it’s dangerous.

Open Source Vulnerability Analysis
Most security problems in open source software require certain conditions to be met in order for an application to be vulnerable. It may be that an attacker has to be able to get arbitrary data to a particular function argument, or a particular class must be used. Sometimes the application needs to set up a library with a particular non-default configuration. “Vulnerability analysis” (also called “attackability analysis,” “exploitability analysis,” or “reachability analysis”) involves analyzing whether the conditions for triggering a vulnerability exist in the target application. It typically relies on static analysis to compute an approximation of what the program will do at runtime. I’ve previously discussed both the value and the pitfalls of “attackability” based prioritization.

It is this approximate nature of static analysis that carries risk. Vulnerability analysis can certainly be helpful for prioritizing work, but it should never be used as an excuse to ignore a high-severity vulnerability.

False Positives and False Negatives
Most questions in static analysis are undecidable – a technical term that means there is (Read more…)

*** This is a Security Bloggers Network syndicated blog from Sonatype Blog authored by Stephen Magill. Read the original post at: https://blog.sonatype.com/despite-what-some-vendors-say-please-dont-ignore-log4j