Over the last few months, following the scramble that was Log4j, I have been asking folks I meet "what if another critical vulnerability was announced tomorrow? What would you do differently?" Well, last Wednesday, we got a reminder that new security vulnerabilities can and do appear.
Spring4Shell, a previously unannounced and badly named Remote Code Execution (RCE) flaw, began as a series of rumors, first through qq messages followed by rumors on the Twitter-sphere. These then quickly cascaded into blogs that took partial information into canon.
From there, the situation has clarified - there was a RCE and its severity is listed as "Critical," but with some important caveats, namely that it affects those:
-
Running the application packaged as a WAR
-
Within the Tomcat environment
-
On JDK 9 or newer
-
That include spring-beans through a
spring-webmvcorspring-webfluxdependency -
Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions
This configuration is fortunately non-standard, as most Spring apps are now Spring Boot (insert sigh of relief here). The name, by the way, has nothing to do with Log4shell - but it probably raised the attention for this particular issue to a new level.
But why did the collective developer sphere skip a beat when the rumors first began to circulate?
Spring is mega-popular framework
Spring ranks in the top 3 in developer popularity in Java Frameworks, according to several different reports over the years, and its embrace by the community is comparable to Log4j. Developers like how Spring helps them write more efficiently by providing them with pre-made templates and utilities.
This translates to a lot of potentially affected deployments, which at first glance may seem like easy pray. The reality however is that due to the mitigating circumstances, only a small percentage of deployments are truly vulnerable to the issue. That said, with any big project, there is a ton of legacy out there that can result in older and unmaintained systems becoming potential entry points.
Introducing Spring4Shell Resource Center
We're proud to introduce the Spring4Shell dashboard to help researchers and interested parties track how the world is adopting these new fixes. As custodians of Maven Central, the canonical Java library, we are in a unique position to share how the world is fixing this issue.
Our hope is not to bash The Spring framework. Vulnerabilities are liable to exist in any major piece of software and indeed we see hundreds of them on a weekly basis. We want to highlight how quickly adoption happens when a severe vulnerability with an available patch is available and mitigating conditions are announced.
When Log4j happened, we took the step to publish adoption statistics. This contributes to awareness of how fast the world is remediating this issue. Sadly, even with all of the awareness out there - today on average about 40% of all downloads of log4j2 are still for vulnerable versions affected by Log4Shell.
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. How do we as an industry react when we know we have a vulnerability that does have public advisories for immediate upgrade, but not at the level where they get an insert on CNBC?
How fast are the new patched versions being adopted?
At publish time, 87% of the component downloads for the spring-beans artifact (containing the vulnerable code) are still to older, potentially vulnerable versions. The higher the number, the more unpatched products are still being built.
What is interesting about this statistic is both the story it tells us about how fast any new patches are adopted, as well as what difference the mitigating circumstances might make. The 'vulnerable' vs 'patched' download rates are probably lower that expected at first glance. Although some portion of downloads might be cached, some by security researchers and some by developers building legacy software, it does give you a good overall indication of global sentiment. It also tells the tale of how fast the security concern is heard on the development planning floor.
The aggregate rate of adopting fixes can be observed in the second diagram on the dashboard that illustrates a stacked view of the download ratios. Over time, this diagram highlights the rate of patched version adoption. Even at this early stage, we can already see a slower rate of update adoption compared to Log4j. This is most likely due to the vulnerability only affecting some Spring users in specific configurations. This graph will help us understand the fixed adoption rate in the days and weeks ahead.
We believe this highlights how merely looking at downloads is not enough. As an industry we have a long way to go in informing our wider community about fixes available and in our methods for adopting them.
How is the world adopting fixes?
Because the Log4j vulnerability saw dramatic levels of adoption in different regions, we dug further into the data to observe those same differences in Spring.
Below, you can see this analysis separated by country. We looked at the top countries by download volume and their differences in adoption rates. So far, things have remained fairly consistent - it'll be useful to see how this evolves over time.
The Percentage Vulnerable downloads graph will illustrate the difference between these top countries, and their rate of adoption. With Log4j, we noticed that they generally fell into three clusters - high adopters, a large middle pack and lagging adopters.
This is further illustrated by the map view, which presents the country-by-country adoption view. This allows us to visually see the difference in the download ratios.
Countries with less overall downloads will typically come up most remediated first. Larger countries with larger developer populations naturally are slower to adopt. It'll be interesting to see how different regions react to advisories and have overall developer awareness of the issue.
Putting things into perspective
To ensure that the numbers are not seen just in isolation, we are providing everyone visiting the dashboard with information about what needs to be done to remediate the issues, as well as what the currently known attacks are. Our intention is to highlight how we as an industry are reacting to an ongoing significant patch, and our hope is that it’ll help drive awareness about how the "software economy" reacts to these exceptional situations.
Vulnerabilities do happen - and ignoring them can lead to serious security breaches or increased technical debt. Understanding the anatomy of our remediation cycles helps us become better at dealing with new and unprecedented scenarios. Companies should look at their current capability to adopt changes at a rapid pace even when just adopting lesser fixes. We here at Sonatype continue to help our customers and the wider open source community do just that.
Head on over to the Spring4Shell dashboard - and if you'd like here are some other historical pieces of research for further reading.
If you want to find out if your software is affected by this or any other vulnerability, why not try a free scan with Sonatype Vulnerability Scanner.
