0

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!

meeque
  • 13
  • 3
  • I *think* [this](https://github.com/spring-projects/spring-framework/commit/90cfde985ef08e8372ffefda2156f8091f65efe6) is the patch for the CVE you linked and yes, it seems like one needs to be able to run arbitrary SpEL to exploit that, causing an OOM error (from a seemingly harmless expression). – Joachim Sauer Apr 11 '22 at 14:12
  • Thanks, @JoachimSauer. But should't this be an answer rather than a comment? Fyi, the commit that you mentioned is very similar to the one that I've already posted in the question. The two just fix the problem on different branches, "5.2.x" and "main" respectively. – meeque Apr 12 '22 at 12:43
  • I'm not confident enough about the correctness of my information and if it actually answers your question ;-) If it does, feel free to post the equivalent as an answer and self-accept. – Joachim Sauer Apr 12 '22 at 12:47

1 Answers1

2

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);
  • 1
    Thank you! I wasn't even aware of that original advisory, because NVD does not list it at [CVE-2022-22950](https://nvd.nist.gov/vuln/detail/CVE-2022-22950). But indeed, it answers my two questions. Let me paraphrase: 1. This CVE is only relevant for applications that use SimpleEvaluationContext. Other evaluation contexts are free-for-all anyway. DoS, RCE, you name it. 2. To exploit this CVE, an attacker must be able to inject snippets of SpEL code. Injecting data that will be processed by an existing SpEL expression will generally not be enough to cause DoS. – meeque May 12 '22 at 16:57