The maintainers of the popular Spring framework patched the critical remote code execution flaw (CVE-2022-22965) on March 31. Two weeks later, the majority of the Spring downloads are still using vulnerable versions with the flaw unpatched, suggesting developers are not in a rush to upgrade.
As of April 15, 77% of Spring downloads were for vulnerable versions, according to the charts posted by Sonatype on its Exploit Resource Center. That is a small drop from April 4, when 82% of Spring downloads were for vulnerable versions of the framework. There was a quick jump to about 20% of downloads adopting the latest versions, but since then, the figure has leveled off. One reason why the vulnerable versions of Spring are still being downloaded may be tied to the fact that many companies do not have a clear understanding of all the dependencies for each business applications.
“[The] fact that we continue to see these downloads is indicative that organizations haven’t made the decision to upgrade,” says Brian Fox, Sonatype’s CTO.
In the above stacked area chart, the red region represents the vulnerable versions and the green region the updated version with the fix pathed. In this case, the higher the number, the more applications with the vulnerable component being built.
The needle towards the majority of developers using the updated version is moving very slowly.
Preparing for the Future
The vulnerability’s exploitability can change at any time – as someone may develop an attack vector that is repeatable and doesn’t require as many specific conditions to be present, or may figure out a way to get around security mitigations. It would be better to get the environment updated now before a newer exploit is developed and the situation becomes more serious.
“[The] danger is, when the cone of attention moves on, there will be plenty of unpatched estate that might later become a risk,” notes Iikka Turunen, Sontaype’s field CTO. “It’s not a a spring thing, it’s a how are we managing our dependencies thing.”
The vulnerability exists in Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older. The issue has been fixed in Spring Framework version 5.3.18 and 5.2.20 and Spring Boot 2.5.12 and 2.6.6.
“This seems to indicate that those who know they need to upgrade — and are able to — tend to do so very quickly,” Fox says. “The rest of the long tail, however, is very long, leaving lots of room for attackers to find new ways to exploit the existing vulnerabilities and to work around the mitigations that may be in place.”
Not “as bad” as Log4j
Back in December, when the vulnerability in Log4j was disclosed, there was a big push to get people to update as soon as possible. Sonatype says its latest numbers show that 34% of Log4j downloads are still the vulnerable version. The majority of new downloads are for the latest – safe – version.
Despite its severity, the issue in Spring isn’t viewed as being just as urgent because exploitation requires a non-standard setup (packaged as a traditional WAR file when most modern applications have switched to Spring Boot executable jar files) and exploitation is currently very limited.
“Spring4Shell does give us a unique opportunity to understand what happens in the software industry when ‘Critical’ but not ‘The Internet is on Fire’-level vulnerabilities appear,” Turunen says.
To underscore the rarity, vulnerability scanning and penetration testing services company Intruder scanned over 25,000 client assets since the disclosure of the vulnerability. “We have yet to find a vulnerable application,” writes Benjamin Marr, a security engineer with Intruder.
Security teams should not get complacent or delay the upgrades. “There will inevitably be more ways to exploit through adjacent methods,” Fox says. “The safest thing to do in these scenarios, almost always, is upgrade.”
Source: www.darkreading.com