Search code examples
springspring-eldenial-of-servicecve

Preconditions for SpEL DoS vulnerability CVE-2022-22950?


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 unrestricted EvaluationContext 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 permissive EvaluationContext?

  • 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!


Solution

  • 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 than EvaluationContext) 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 -

    SpelExpressionParser parser = new SpelExpressionParser();
    Expression expr = parser.parseExpression("new int[1024*1024*1024][2]");
    SimpleEvaluationContext context = SimpleEvaluationContext.forReadOnlyDataBinding().build();
    expr.getValue(context);