Spring officially fixes zero-day vulnerabilities and launches new versions of Spring Boot 2.6.6, 2.5.12, etc.

1. Vulnerability Description

This vulnerability has to start from the evening of March 29th.

At that time, many netizens broke the news that there was an "epic" RCE vulnerability in the Spring framework, and there was a thunderous sound. All of a sudden, developers who were about to fall asleep sat up to check the situation about the vulnerability, which made people in the technical circle panic.

However, it is somewhat unusual that this vulnerability did not cause urgent actions by many large companies in the circle like the Log4j2 incident. Even the source of the vulnerability disclosed abroad came from QQ and some domestic network security websites.

Spring officially confirmed: Framework explosion, JDK 9 and above versions are affected

This also led many netizens to speculate that the vulnerability should have been first discovered by a domestic security agency and security personnel.

Sure enough, according to the " Security Bulletin on Remote Command Execution Vulnerabilities in Spring Framework " released by the National Information Security Vulnerability Sharing Platform (CNVD) on March 31 , this group of mysterious white hats includes Ant Technology Group, Qi Anxin Technology, Hangzhou Anheng Information Technology, Antiy Technology, 360, Beijing Tianrongxin, of course, these are for later.

1.1 Spring zero-day vulnerabilities really exist

Just as developers were getting more and more anxious, Spring.io officials came forward on the evening of March 31 to confirm the existence of this vulnerability and brought a solution.

Spring officially confirmed: Framework explosion, JDK 9 and above versions are affected

According to the announcement, we found that the impact of this vulnerability is far more serious than we thought. If the following thresholds are met, it is very likely to be affected by the vulnerability:

  • JDK 9 or later

  • Apache Tomcat as a servlet container

  • Packaged as a traditional WAR (compared to Spring Boot executable jar)

  • spring-webmvc or spring-webflux dependencies

  • Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19 and earlier

2. Official update

2.1 Preliminary solution

Currently Spring.io has released Spring Framework 5.3.18 and 5.2.20 versions, and also brings the latest Spring Boot 2.6.6 and 2.5.12 which depend on Spring Framework 5.3.18 . Because if you can upgrade to Spring Framework 5.3.18 and 5.2.20, the following fixes are not needed.

If not, Spring officially recommends setting disallowedFields of WebDataBinder through @ControllerAdvice.

@ControllerAdvice@Order(Ordered.LOWEST_PRECEDENCE)public class BinderControllerAdvice { @InitBinder public void setAllowedFields(WebDataBinder dataBinder) { String denylist = new String{"class.*", "Class.*", "*.class.*", "*.Class.*"}; dataBinder.setDisallowedFields(denylist); }}

This solution usually works, but it's not 100% able to prevent the vulnerability. So to be more secure, Spring.io also recommends that applications can extend
RequestMappingHandlerAdapter and update WebDataBinder at the end after all other initializations. To achieve this, Spring Boot applications can declare a WebMvcRegistrations (Spring MVC) or WebFluxRegistrations bean (Spring WebFlux).

In Spring MVC (and similarly in WebFlux) the example is as follows:

package vip.mate.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.web.servlet.WebMvcRegistrations;
import org.springframework.context.annotation.Bean;
import org.springframework.web.bind.ServletRequestDataBinder;
import org.springframework.web.context.request.NativeWebRequest;
import org.springframework.web.method.annotation.InitBinderDataBinderFactory;
import org.springframework.web.method.support.InvocableHandlerMethod;
import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter;
import org.springframework.web.servlet.mvc.method.annotation.ServletRequestDataBinderFactory;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;

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

    @Bean
public WebMvcRegistrations mvcRegistrations() {
        return new WebMvcRegistrations() {
            @Override
public RequestMappingHandlerAdapter getRequestMappingHandlerAdapter() {
                return new ExtendedRequestMappingHandlerAdapter();                
            }
        };
    }

    private static class ExtendedRequestMappingHandlerAdapter extends RequestMappingHandlerAdapter {
        @Override
protected InitBinderDataBinderFactory createDataBinderFactory(List<InvocableHandlerMethod> methods) {
            return new ServletRequestDataBinderFactory(methods, getWebBindingInitializer()) {
                @Override
protected ServletRequestDataBinder createBinderInstance(Object target, String name, NativeWebRequest request) throws Exception {                        
                    ServletRequestDataBinder binder = super.createBinderInstance(target, name, request);
                    String[] fields = binder.getDisallowedFields();
                    List<String> fieldList = new ArrayList<>(fields != null ? Arrays.asList(fields) : Collections.emptyList());
                    fieldList.addAll(Arrays.asList("class.*", "Class.*", "*.class.*", "*.Class.*"));
                    binder.setDisallowedFields(fieldList.toArray(new String[]{}));
                    return binder;
                }
            };
        }
    }
}

For Spring MVC without Spring Boot, applications can switch from @EnableWebMvc to extending
DelegatingWebMvcConfiguration directly, as in this documentation (https://docs.spring.io/spring-framework/docs/current/reference/html/web.html #mvc-config-advanced-java) as described in the Advanced Configuration section, and then override the  createRequestMappingHandlerAdapter method.

Based on the above, we recommend that product (service) manufacturers and information system operators affected by the vulnerability conduct self-inspection as soon as possible and upgrade to the latest version in a timely manner.

 

 

Guess you like

Origin www.oschina.net/news/189407