Spring corrige oficialmente las vulnerabilidades de día cero y lanza nuevas versiones de Spring Boot 2.6.6, 2.5.12, etc.

1. Descripción de la vulnerabilidad

Esta vulnerabilidad tiene que comenzar a partir de la noche del 29 de marzo.

En ese momento, muchos internautas dieron la noticia de que había una vulnerabilidad RCE "épica" en el marco de Spring, y hubo un sonido atronador. De repente, los desarrolladores que estaban a punto de quedarse dormidos se sentaron para verificar la situación sobre el vulnerabilidad, lo que hizo que la gente en el círculo técnico entrara en pánico.

Sin embargo, es algo inusual que esta vulnerabilidad no haya causado acciones urgentes por parte de muchas grandes empresas en el círculo como el incidente de Log4j2 Incluso la fuente de la vulnerabilidad revelada en el extranjero provino de QQ y algunos sitios web de seguridad de redes nacionales.

Primavera confirmada oficialmente: explosión de Framework, JDK 9 y versiones superiores se ven afectadas

Esto también llevó a muchos internautas a especular que la vulnerabilidad debería haber sido descubierta primero por una agencia de seguridad nacional y personal de seguridad.

Efectivamente, según el " Boletín de seguridad sobre la vulnerabilidad de ejecución de comandos remotos en Spring Framework " publicado por la Plataforma de intercambio de vulnerabilidades de seguridad de la información nacional (CNVD) el 31 de marzo , este grupo de misteriosos sombreros blancos incluye Ant Technology Group, Qi Anxin Technology, Tecnología de la información de Hangzhou Anheng, tecnología Antiy, 360, Beijing Tianrongxin, por supuesto, estos son para más adelante.

1.1 Las vulnerabilidades de día cero de Spring realmente existen

Justo cuando los desarrolladores estaban cada vez más ansiosos, los funcionarios de Spring.io se presentaron la noche del 31 de marzo para confirmar la existencia de esta vulnerabilidad y brindaron una solución.

Primavera confirmada oficialmente: explosión de Framework, JDK 9 y versiones superiores se ven afectadas

Según el anuncio, descubrimos que el impacto de esta vulnerabilidad es mucho más grave de lo que pensábamos. Si se cumplen los siguientes umbrales, es muy probable que se vea afectado por la vulnerabilidad:

  • JDK 9 o posterior

  • Apache Tomcat como contenedor de servlets

  • Empaquetado como un WAR tradicional (en comparación con el archivo ejecutable Spring Boot)

  • dependencias spring-webmvc o spring-webflux

  • Spring Framework versiones 5.3.0 a 5.3.17, 5.2.0 a 5.2.19 y anteriores

2. Actualización oficial

2.1 Solución preliminar

Actualmente, Spring.io ha lanzado las versiones Spring Framework 5.3.18 y 5.2.20 , y también trae las últimas Spring Boot 2.6.6 y 2.5.12 que dependen de Spring Framework 5.3.18 . Porque si puede actualizar a Spring Framework 5.3.18 y 5.2.20, las siguientes correcciones no son necesarias.

De lo contrario, Spring recomienda oficialmente establecer campos no permitidos de WebDataBinder a través de @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); }}

Esta solución suele funcionar, pero no es 100% capaz de prevenir la vulnerabilidad. Entonces, para ser más seguro, Spring.io también recomienda que las aplicaciones puedan extender
RequestMappingHandlerAdapter y actualizar WebDataBinder al final después de todas las demás inicializaciones. Para lograr esto, las aplicaciones Spring Boot pueden declarar un bean WebMvcRegistrations (Spring MVC) o WebFluxRegistrations (Spring WebFlux).

En Spring MVC (y de manera similar en WebFlux) el ejemplo es el siguiente:

paquete vip.mate.demo; importar org.springframework.boot.SpringApplication;
importar org.springframework.boot.autoconfigure. Aplicación SpringBoot ;
importar org.springframework.boot.autoconfigure.web.servlet.WebMvcRegistrations;
importar org.springframework.context.annotation. frijol ;
importar org.springframework.web.bind.ServletRequestDataBinder;
importar org.springframework.web.context.request.NativeWebRequest;
import org.springframework.web.method.annotation.InitBinderDataBinderFactory;
importar org.springframework.web.method.support.InvocableHandlerMethod;
importar

org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter;
import org.springframework.web.servlet.mvc.method.annotation.ServletRequestDataBinderFactory; importar java.util.ArrayList;
importar java.util.Arrays;
importar java.util.Collections;
importar java.util.List; @SpringBootApplication
 public class MyApp {
     public static void main(String[] args) { 
        SpringApplication. ejecutar (MiAplicación. clase , argumentos); 
    } @Bean
 public WebMvcRegistrations mvcRegistrations() {
         volver nuevo





        WebMvcRegistrations() {
             @Override
 public RequestMappingHandlerAdapter getRequestMappingHandlerAdapter() {
                 return new ExtendedRequestMappingHandlerAdapter(); 
            } 
        }; 
    } clase estática privada ExtendedRequestMappingHandlerAdapter extiende RequestMappingHandlerAdapter {
         @Override
 protected InitBinderDataBinderFactory createDataBinderFactory(List<InvocableHandlerMethod> métodos) {
             return new ServletRequestDataBinderFactory(methods, getWebBindingInitializer()) {
                 @Override
 protected            

                            ServletRequestDataBinder createBinderInstance (objetivo objetivo, nombre de cadena, solicitud NativeWebRequest) arroja una excepción { 
                    ServletRequestDataBinder binder = super .createBinderInstance (objetivo, nombre, solicitud); 
                    String[] campos = binder.getDisallowedFields(); 
                    List<String> fieldList = new ArrayList<>(fields != null ? Arrays. asList (fields) : Collections. emptyList ()); 
                    fieldList.addAll(Arrays. asList ( "clase.*" , "Clase.*" , "*.clase.*" , "*.Clase.)); 
                    binder.setDisallowedFields(fieldList.toArray( new String[]{}));
                    aglutinante de retorno ; 
                } 
            }; 
        } 
    } 
}

Para Spring MVC sin Spring Boot, las aplicaciones pueden cambiar de @EnableWebMvc a extender
DelegatingWebMvcConfiguration directamente, como en esta documentación (https://docs.spring.io/spring-framework/docs/current/reference/html/web.html #mvc -config-advanced-java) como se describe en la sección Configuración avanzada y, a continuación, invalide el  método createRequestMappingHandlerAdapter.

Con base en lo anterior, recomendamos que los fabricantes de productos (servicios) y los operadores de sistemas de información afectados por la vulnerabilidad realicen una autoinspección lo antes posible y actualicen a la última versión de manera oportuna.

 

 

Supongo que te gusta

Origin www.oschina.net/news/189407
Recomendado
Clasificación