Spring Core on JDK9 is vulnerable to remote code execution

I've spent most of my day on this and can confirm there is serious potential to this. It's not a log4shell but it's serious.

You're potentially vulnerable if you use POJOs as request parameters[0] with Spring MVC and Java 9+. To support complex POJOs (like a POJO in a POJO), Spring uses the `.` separator. Therefore, you can have a request GET /somePath?innerPojo.field=foo that will get mapped properly [1].

Now, in [2], the `getCachedIntrospectionResults()` result has a `class` parameter that I believe should not be exposed. In this object, there's a bunch of parameters that can be set, that's where the problem is. In the POC seen across the web today, it was modifying the `AccessLogValve` of Tomcat. The exploit mentioned in [3] relies on passing a parameter like this :

GET /somePath?class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp

This will access the `class` object and uses the `getModule` method of the `Class` object to get the `Module` class. Now, this class has the `ClassLoader` exposed via a getter BUT it's exposed as opposed to the `Class` class[4]! In the POC, it's an instance of `WebAppClassLoaderBase` (when using Tomcat, under some circumstances). This class has a `getResources` method that is accessed here, along with `getContext`, `getParent`, etc. all the way up to the last delimiter which invoke the `setSuffix` method of the `AccessLogValve` instance [5]. Rinse and repeat this to set the tone for the JSP vulnerability and you have a RCE.

Now, this needs some specific preconditions. However, there are probably hundred of other mutable objects accessible this way that could lead to pretty nasty bugs, vulnerability of information disclosures.

Finally, I can confirm that the workaround with `@InitBinder` mentioned in [6] works.

EDIT : Looks like a regression from CVE-2010-1622 that was fixed in [7].

[0] https://docs.spring.io/spring-framework/docs/3.2.x/spring-fr...

[1] https://gist.github.com/jebeaudet/127e6fb0b59e06c0642d2f362e...

[2] https://github.com/spring-projects/spring-framework/blob/mai...

[3] https://www.cyberkendra.com/2022/03/spring4shell-details-and...

[4] https://github.com/spring-projects/spring-framework/blob/mai...

[5] https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob...

[6] https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vu...

[7] https://github.com/spring-projects/spring-framework/commit/3...

I have never seen that class SerializationUtils used in the wild. Now if it was in Jackson...

Frameworks like Quarkus and Micronaut do this at compile time. They dynamically load things and record it, then insert the resulting bytecode statically in the build artifact. I believe the core motivator is performance, but it has the added benefit of eliminating most of the runtime magic that leads to vulnerabilities like this.

Not my field, but how can this be so? We had MVC in 1990 written in C or C++.

Not sure why it's tagged JDK9+, but 'class' attribute is accessible on org.springframework.beans.BeanWrapperImpl.getLocalPropertyHandler() in JDK 8 also. It probably doesn't matter which JDK is being used, as long as this spring-beans dependency is used.

Whether logging JSP exploit in JDK 8 or lower can be used is another question. However, since 'class' is accessible via request parameter, it's already bad and there will probably be some ways to exploiting it. It doesn't matter whether the request is GET or POST, as long as mapped controller method uses a non-primitive request object, 'class' can be accessed. 'class.module' attribute is accessible from Java 9 and above, I tested on Java 11 and can access 'class.module'. Sample code that I used to test this with JDK 8 is below. I just tested whether 'class' attribute can be accessed via request parameter.

curl -X POST localhost:8080/test?class.modifiers=Hello

package com.test;

    import org.springframework.boot.SpringApplication;
    import org.springframework.boot.autoconfigure.SpringBootApplication;
    import org.springframework.web.bind.annotation.PostMapping;
    import org.springframework.web.bind.annotation.RestController;

    @SpringBootApplication
    public class Spring4ShellTestApplication {

    public static void main(String[] args) {
      SpringApplication.run(Spring4ShellTestApplication.class, args);
     }

    }
    @RestController
    class TestController {

    @PostMapping("/test")
     public String test(TestOuterRequest request) {

      String message = "Inner request is null";

      if (request.getInnerRequest() != null) {
       message = "your message was: " + request.getInnerRequest().getMessage();
      }

      System.out.println(message);

      return message;
     }
    }

    class TestOuterRequest {
     private TestInnerRequest innerRequest;

    public TestInnerRequest getInnerRequest() {
      return innerRequest;
     }

    public void setInnerRequest(TestInnerRequest innerRequest) {
      this.innerRequest = innerRequest;
     }
    }

    class TestInnerRequest {
     private String message;

    public String getMessage() {
      return message;
     }

    public void setMessage(String message) {
      this.message = message;
     }
    }

Finally here are the attributes that're exposed on 'class' as accessible properties in JDK 8 (JDK9+ adds 'module' on top of all these)

    annotatedInterfaces
    annotatedSuperclass
    annotation
    annotations
    anonymousClass
    array
    canonicalName
    class
    classes
    componentType
    constructors
    declaredAnnotations
    declaredClasses
    declaredConstructors
    declaredFields
    declaredMethods
    declaringClass
    enclosingClass
    enclosingConstructor
    enclosingMethod
    enum
    enumConstants
    fields
    genericInterfaces
    genericSuperclass
    interface
    interfaces
    localClass
    memberClass
    methods
    modifiers
    name
    package
    primitive
    signers
    simpleName
    superclass
    synthetic
    typeName
    typeParameters