Were you unable to attend Transform 2022? Check out all of the summit sessions in our on-demand library now! Watch here.
Patches are now available for the Spring4Shell vulnerability, and security teams are continuing to assess the potential for the remote code execution (RCE) flaw to affect applications. But as of this writing, there continues to be little evidence of widespread risk from the recently disclosed Spring Core vulnerability.
Organizations are encouraged to assess the situation for themselves to determine their level of risk exposure, according to security professionals including Chris Partridge, who has compiled details about the Spring4Shell vulnerability on GitHub.
However, “thus far nobody’s found evidence that this is widespread,” Partridge said on the GitHub page. “This is a severe vulnerability, sure, but it only impacts non-default usage of Spring Core with no proven widespread viability. It’s categorically not log4shell-like.”
In a message to VentureBeat, Partridge said that “it’s great that Spring is taking this fix seriously. Hopefully, no bypasses are found.”
MetaBeat will bring together thought leaders to give guidance on how metaverse technology will transform the way all industries communicate and do business on October 4 in San Francisco, CA.
Spring is a popular framework used in the development of Java web applications.
On Thursday, Spring published a blog post with details about patches, exploit requirements and suggested workarounds for Spring4Shell. The RCE vulnerability, which is being tracked at CVE-2022-22965, affects JDK 9 or higher and has several additional requirements for it to be exploited, the Spring blog post says.
Among other things, the blog post confirms that the Spring4Shell vulnerability is not Log4Shell 2.0, said Ian McShane, vice president of strategy at Arctic Wolf.
“It’s an RCE, so it’s a high-priority risk. But the fact that it needs a non-default implementation should limit the scope, especially compared with Log4Shell,” McShane said in an email.
The Apache Log4j logging software — which was impacted by the Log4Shell vulnerability disclosed in December — was embedded in countless applications and services and was vulnerable by default, he noted.
Spring4Shell, by contrast, “doesn’t seem to be a comparable risk. But that doesn’t mean organizations can ignore it,” McShane said. “As with all application vulnerabilities, especially ones that are internet-facing by design, you need to find out if you are at risk before you discount it.”
Despite the similar naming to Log4Shell, it’s now clear that Spring4Shell is “definitely not as big,” said Satnam Narang, staff research engineer at Tenable.
“That said, we’re still in the early phases of figuring out what applications out there might be vulnerable, and we’re basing this on what’s known,” Narang said in an email. “There are still some question marks around if there are other ways to exploit this flaw.”
If anything, though, the blog post from Spring only narrows the range of vulnerable instances, said Mike Parkin, senior technical engineer at Vulcan Cyber.
And by clarifying the exploitable conditions, the update gives the security community a more-accurate picture of potential risk, Parkin said.
“However, attackers may find creative ways to leverage this vulnerability beyond the identified target range,” he said in an email. At the moment, though, there are no reports of the vulnerability being exploited in the wild, Parkin noted.
John Bambenek, principal threat hunter at Netenrich, agreed that the vulnerability appears to affect fewer machines as compared to Log4Shell.
There are some specific environments that Spring4Shell may apply to, “but the more dangerous case of embedded or vendor-provided machines are less likely to see this vulnerability,” Bambenek said.
More info still needed
In an update to its blog post on the RCE vulnerability, Flashpoint and its Risk Based Security unit said that because Spring Core is a library, “The exploit methodology will likely change from user to user.”
“More information is needed to assess how many devices run on the needed configurations,” the updated Flashpoint blog post says.
Colin Cowie, a threat analyst at Sophos, and vulnerability analyst Will Dormann separately posted confirmations Wednesday, showing that they were able to get an exploit for the Spring4Shell vulnerability to work against sample code supplied by Spring.
“If the sample code is vulnerable, then I suspect there are indeed real-world apps out there that are vulnerable to RCE,” Dormann said in a tweet.
Still, as of this writing, it’s not clear which specific applications might be vulnerable.
The bottom line is that Spring4Shell is “definitely cause for concern — but seems to be quite a bit more difficult to successfully exploit than Log4j,” said Casey Ellis, founder and CTO at Bugcrowd, in an email.
In any case, given the large volume of research and discussion around Sping4Shell, defenders would be well-advised to mitigate — and/or patch — as soon as possible, Ellis said.
It’s also likely that new flavors of this vulnerability could emerge in the near future, said Yaniv Balmas, vice president of research at Salt Security. “These could impact other web servers and platforms and widen the reach and potential impact of this vulnerability,” Balmas said in an email.
VentureBeat's mission is to be a digital town square for technical decision-makers to gain knowledge about transformative enterprise technology and transact. Discover our Briefings.