Two different “VMware Spring” bugs at large – we cut through the confusion


Yesterday, we wrote about a bug in the VMware Spring product, a project we described as “An open-source Java toolkit for building powerful Java apps, including cloud-based apps, without the need to write, manage, worry about, or even understand the ‘server’ part of the process yourself.”

RELATED POSTS

But Spring is a huge project, with a vast number of components, so talking about “a vulnerability in Spring” is a bit like saying “I think there’s a bug in Windows”, or “I hope I don’t catch the Sickness disease”.

So, to make things a bit clearer, the bug we looked at yesterday is officially designated CVE-2022-22963and its semi-official long name is Remote code execution in Spring Cloud Function by malicious Spring Expression

You might also see it referred to as Spring Expression Resource Access Vulnerabilitysometimes written as SPEL Vulnerability“. (SPEL, also written SpEL, is itself short for “Spring Expression Language”, which is the technology abused when this bug is exploited.)

The CVE-2022-22963 bug exists in a Spring component called Spring Cloud Functionwhich is an optional module that you can use inside the Spring ecosystem to write your Spring code in what’s known as a functional style, where you strip back the code needed for data processing to a minimum.

For example, if you want a web service to convert a SKU into a product name, a functional approach would let you program that as a simple function that took the SKU as an input, returned the name as an output, and didn’t need to concern itself with any of the surrounding details of how to receive the input, or how to return the result to the caller.

Unfortunately, by adding a special HTTP header to the request sent into the Spring Cloud Function module (the very code that saved you from writing code to process the request!), an attacker could trick the server into running a program of their choice.

This sort of vulnerability is known as Remote Code Execution (RCE), which is a jargon term that means just what is saying: someone from the outside, perhaps even on the other side of the world, can trick your computer into running a program of their choice, without the usual warnings or popups you would expect before inviting untrusted code into your network.

RCEs are always a serious issue, even if they’re hard to exploit or rely on a non-default configuration of the service being attacked.

After all, the ability to force someone else to run code they didn’t choose themselves often means that an attacker could quietly implant malware without needing to figure out a way to login first.

Worse still, proof-of-concept (PoC) exploits showing how to abuse CVE-2022-22963 are readily available online, so that wannabe cybercriminals can simply copy-and-paste existing code to get started with an attack.

Fortunately, patching against the CVE-2022-22963 bug is easy: if you use the Spring Cloud Function module anywhere in your Spring-based ecosystem, upgrade to version 3.1.7 or 3.2.3depending on which of the two officially supported branches of Spring Cloud Function you have.

For official information, see the Spring team’s CVE Report and its own vulnerability assessment.