CVE-2024-38807

• Produto afetado:^Spring® Boot
• Pacotes afetados:
  • spring-boot-loader
  • spring-boot-loader-classic
• Versões afetadas:
  • 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
• Repositório do GitHub: https://github.com/spring-projects/spring-boot
• Pacotes publicados:

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

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

• Corrigido na versão: ELS para^Spring® Boot v2.7.18.TuxCare.4, que tem como base a última versão 2.7.18 da comunidade de código aberto, à qual foram aplicados todos os patches da TuxCare.

As aplicações^Spring® Boot empacotadas com o ^Spring® Boot Loader utilizam um carregador de classes personalizado para iniciar aplicações a partir de um “JAR completo” (ou seja, com todas as dependências incluídas). Esse JAR contém JARs aninhados na pasta /BOOT-INF/lib.

A vulnerabilidade está na forma como o mecanismo de verificação de assinatura do Java é tratado para esses JARs aninhados. Se um aplicativo tentar verificar a assinatura digital de um JAR aninhado usando APIs padrão do JDK, a verificação pode ser considerada bem-sucedida de forma incorreta, mesmo que o JAR aninhado:

• não foi assinado pela entidade esperada, ou
• foi adulterado após ter sido assinado.

Isso ocorre porque o^Spring® Boot Loader não preserva totalmente o contexto de verificação do JAR assinado ao extrair e carregar JARs aninhados.

Isso não afeta a maioria dos usuários^{do Spring®} Boot, a menos que implementem explicitamente uma lógica personalizada de validação de assinatura digital para JARs aninhados.

Por que isso é um problema?

O^Spring® Boot empacota aplicativos em JARs autônomos usando o spring-boot-loader, que inclui:

• Classes de aplicativos (BOOT-INF/classes)
• Dependências (BOOT-INF/lib como JARs aninhados)

Se uma organização tentar verificar as assinaturas digitais desses JARs aninhados (por exemplo, para verificar se houve adulteração ou para confirmar a confiabilidade), a verificação pode ser aprovada sem aviso, mesmo que:

• O JAR aninhado foi modificado
• A assinatura foi criada por um signatário inesperado ou mal-intencionado

Por quê? Porque:

• O modelo de assinatura de JARs do Java não foi projetado para JARs aninhados
• O spring-boot-loader extrai e carrega arquivos JAR sem preservar o contexto original de verificação de assinatura

Impacto no mundo real

1. Quebra da confiança na cadeia de suprimentos
   • Você acha que está carregando apenas dependências confiáveis (por exemplo, assinadas pelo seu fornecedor), mas um invasor poderia substituir um JAR, e o aplicativo poderia erroneamente informá-lo como verificado.
2. As ferramentas de segurança podem falhar
   • Lógicas personalizadas, scanners de segurança ou verificadores em tempo de execução que utilizam as APIs do JarFile podem validar incorretamente o conteúdo aninhado que foi modificado.
3. Ameaça interna ou risco de implantação
   • Um pipeline de CI/CD comprometido poderia introduzir arquivos JAR alterados, e você não conseguiria detectar isso por meio de verificações de assinatura.

Cenário de exemplo

• Um aplicativo^Spring® Boot verifica um JAR aninhado (por exemplo, json-lib.jar) usando JarEntry.getCertificates(), esperando uma assinatura confiável.
• Está incluída uma versão modificada ou maliciosa do arquivo json-lib.jar.
• Como é carregado por meio do carregador de classes personalizado do^{Spring® Boot}, as APIs de assinatura do Java retornam uma verificação bem-sucedida.
• O aplicativo executa código não confiável, acreditando que ele seja seguro.

Por que isso é sutil, mas perigoso

• A maioria dos aplicativos não é afetada porque não valida as assinaturas dos arquivos JAR.
• No entanto, em ambientes sensíveis à segurança (por exemplo, setor bancário, defesa ou plataformas de fornecedores), isso compromete as verificações de integridade, levando à possível execução de código ou ao comprometimento de dados.

^{O Spring®} Boot 2.7.x não é mais suportado pela comunidade de código aberto, já que sua data de fim de vida útil foi em 30 de junho de 2023. Isso significa simplesmente que as versões lançadas até essa data não recebem mais atualizações para corrigir esse problema.

‍Os usuários dos componentes afetados devem aplicar uma das seguintes medidas de mitigação:

• Aproveite o Suporte de Ciclo de Vida Ilimitado da TuxCare, que amplia o suporte de segurança regular da comunidade após o fim da vida útil (EoL), e depois basta aplicar nossos patches.
• Atualize para a versão 3.3.3+ da comunidade de código aberto e aceite o risco de não receber mais atualizações de segurança da comunidade a partir de 30 de junho de 2025.
• Como alternativa, procure atualizar para as versões de código aberto mais recentes e recomendadas^{do Spring®} Framework que não sejam afetadas — por exemplo, a versão 3.4.x — e conte com o suporte da comunidade até o final de 2025
• Evite basear-se na verificação de assinatura para JARs aninhados, a menos que utilize mecanismos confiáveis de empacotamento e carregamento.
• Utilize ferramentas de segurança no nível do sistema operacional ou verificadores externos para garantir a integridade dos arquivos JAR.

Você precisa de uma correção para essa vulnerabilidade em alguma outra versão^{do Spring®} Framework? Se sim, entre em contato conosco, estamos aqui para ajudá-lo!

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