38807

• Producto afectado:^Spring® Boot
• Paquetes afectados:
  • spring-boot-loader
  • spring-boot-loader-classic
• Versiones afectadas:
  • 2.7.0 – 2.7.21
  • 3.0.0 – 3.0.16
  • 3.1.0 – 3.1.12
  • 3.2.0 – 3.2.8
  • 3.3.0 – 3.3.2
• Repositorio GitHub: https://github.com/spring-projects/spring-boot
• Paquetes publicados:

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-loader

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-loader-classic

• Corregido en: ELS para^Spring® Boot v2.7.18.TuxCare.4, que se basa en la última versión de código abierto de la comunidad 2.7.18 como referencia, a la que se han aplicado todos los parches de TuxCare.

Las aplicaciones^Spring® Boot empaquetadas con ^Spring® Boot Loader utilizan un cargador de clases personalizado para iniciar aplicaciones desde un «JAR grande» (es decir, con todas las dependencias incluidas). Este JAR incluye JAR anidados dentro de /BOOT-INF/lib.

La vulnerabilidad reside en cómo se gestiona el mecanismo de verificación de firmas de Java para estos JAR anidados. Si una aplicación intenta verificar la firma digital de un JAR anidado utilizando las API estándar del JDK, la verificación podría tener éxito incorrectamente, incluso si el JAR anidado:

• no ha sido firmado por la entidad prevista, o
• fue manipulado después de ser firmado.

Esto se debe a que^Spring® Boot Loader no conserva completamente el contexto de verificación del JAR firmado al extraer y cargar JAR anidados.

Esto no afecta a la mayoría de los usuarios^{de Spring®} Boot, a menos que implementen explícitamente una lógica de validación de firmas digitales personalizada para archivos JAR anidados.

¿Por qué es un problema?

^Spring® Boot empaqueta las aplicaciones en archivos JAR autónomos utilizando spring-boot-loader, que incluye:

• Clases de aplicaciones(BOOT-INF/classes)
• Dependencias(BOOT-INF/lib como JAR anidados)

Si una organización intenta verificar las firmas digitales en estos JARs anidados (por ejemplo, para comprobar la manipulación o verificar la confianza), la verificación puede pasar silenciosamente incluso si:

• El JAR anidado fue modificado
• La firma ha sido creada por un firmante inesperado o malintencionado

¿Por qué? Porque sí:

• El modelo de firma JAR de Java no se diseñó para JAR anidados
• spring-boot-loader extrae y carga JARs sin preservar el contexto original de verificación de firmas

Impacto en el mundo real

1. Desglose de la confianza en la cadena de suministro
   • Crees que estás cargando sólo dependencias de confianza (por ejemplo, firmadas por tu proveedor), pero un atacante podría reemplazar un JAR, y la aplicación podría reportarlo falsamente como verificado.
2. Las herramientas de seguridad pueden fallar
   • La lógica personalizada, los escáneres de seguridad o los verificadores en tiempo de ejecución que utilizan las API de JarFile pueden validar incorrectamente el contenido anidado modificado.
3. Amenaza interna o riesgo de despliegue
   • Un CI/CD pipeline comprometido podría introducir JARs alterados, y usted no lo detectaría a través de comprobaciones de firmas.

Ejemplo

• Una aplicación^Spring® Boot verifica un JAR anidado (por ejemplo, json-lib.jar) utilizando JarEntry.getCertificates() y esperando una firma de confianza.
• Se incluye una versión modificada o maliciosa de json-lib.jar.
• Debido a que se carga a través del cargador de clases personalizado de^{Spring® Boot}, las API de firma de Java devuelven una verificación satisfactoria.
• La aplicación ejecuta código que no es de confianza, creyendo que es seguro.

Por qué es sutil pero peligroso

• La mayoría de las aplicaciones no se ven afectadas porque no validan las firmas JAR.
• Pero en entornos sensibles desde el punto de vista de la seguridad (por ejemplo, banca, defensa o mercados de proveedores), esto socava las comprobaciones de integridad, lo que puede llevar a la ejecución de código o al compromiso de los datos.

^Spring® Boot 2.7.x ya no es compatible con la comunidad de código abierto, ya que su fecha de fin de vida útil fue el 30 de junio de 2023. Esto simplemente significa que las versiones de esa fecha o anteriores no recibirán ninguna actualización para solucionar este problema.

‍Los usuarios de los componentes afectados deben aplicar una de las siguientes mitigaciones:

• Aproveche el soporte de ciclo de vida infinito de TuxCare, que amplía el soporte de seguridad EoL habitual de la comunidad, y luego limítese a aplicar nuestros parches.
• Actualice a la versión 3.3.3+ de la comunidad de código abierto y acepte el riesgo de no recibir más actualizaciones de seguridad de la comunidad a partir del 30 de junio de 2025.
• Como alternativa, realice el esfuerzo de actualizar a las últimas y mejores versiones de código abierto compatibles con^Spring® Framework que no se vean afectadas, por ejemplo, la 3.4.x, y obtenga el apoyo de la comunidad hasta finales de 2025.
• Evite confiar en la verificación de firmas para JARs anidados a menos que utilice mecanismos de empaquetado y carga de confianza.
• Utilice herramientas de seguridad a nivel de sistema operativo o verificadores externos para la integridad de los JAR.

¿Necesita una solución para esta vulnerabilidad en alguna otra versión^{de Spring®} Framework? Si es así, póngase en contacto con nosotros, ¡estamos aquí para ayudarle!

• https://nvd.nist.gov/vuln/detail/CVE-2024-38807
• https://spring.io/security/cve-2024-38807
• https://security.netapp.com/advisory/ntap-20250117-0006