I'm a little confused about CVE-2022-22950 and the corresponding Spring advisory. The latter says that the vulnerability can be exploited through:
[...] specially crafted SpEL expression [...]
However, an application that allows users to craft SpEL expressions, allows these users to do pretty much anything. Including code injection, which has full impact on confidentiality, integrity, and availability. Plenty of other DoS opportunities here. Take this SpEL snippet for example, which executes the pwd
command:
T(java.lang.Runtime).getRuntime().exec("pwd")
This command is fairly harmless, but it could be substituted with anything! Now, SpEL supports different EvaluationContexts which can be used to restrict what is allowed in a SpEL expression. E.g. the SimpleEvaluationContext
forbids type expressions, like the one in the above SpEL snippet.
This leads me to 2 sets of questions:
Is
CVE-2022-22950
even relevant for applications that use an unrestrictedEvaluationContext
for tainted SpEL expressions?
E.g. applications that trust selected users (like admins) enough to allow them executing arbitrary code? Or, ideally, have additional sand-boxing measures in place?
It seems that in such scenarios (questionable as they may be) this DoS vulnerability does not add anything new to the game. Would it make sense to improve the security advisory and warn against processing user-controlled SpEL code in a permissiveEvaluationContext
?Does
CVE-2022-22950
really require a "specially crafted SpEL expression"?
Or could an attacker exploit this DoS vulnerability by crafting data that will be processed by an otherwise harmless SpEL expression? E.g. sending a long list of query parameters to a web application that processes them using a hard-coded SpEL expression?
When I look at the code changes it seems that crafting the data might be enough? If so, the wording of the security advisory should be adjusted!
Looking at the original advisory (translated from Chinese) - https://4ra1n.love/post/Xrym_ZDj3/
It looks like exploiting this does require evaluation of arbitrary SpEL expressions. However - it allows for DoS even when using the
SimpleEvaluationContext
which is normally considered safe (or at least safer thanEvaluationContext
) and for example doesn't allow for RCE even when evaluating an arbitrary expression. But with this vulnerability, it will allow for a DoS.The vulnerable code shown in the advisory -