Exploration détaillée de38807
Informations sur les vulnérabilités
Les applicationsSpring® Boot packagées avec Spring® Boot Loader utilisent un chargeur de classes personnalisé pour lancer les applications à partir d'un « fat JAR » (c'est-à-dire contenant toutes les dépendances). Ce JAR comprend des JAR imbriqués dans /BOOT-INF/lib.
La vulnérabilité réside dans la manière dont le mécanisme de vérification de la signature de Java est géré pour ces JAR imbriqués. Si une application tente de vérifier la signature numérique d'un JAR imbriqué à l'aide des API standard du JDK, la vérification peut être incorrectement réussie, même si le JAR imbriqué :
- n 'a pas été signé par l'entité attendue, ou
- a été falsifié après avoir été signé.
En effet, le chargeurSpring® Boot ne conserve pas entièrement le contexte de vérification du fichier JAR signé lors de l'extraction et du chargement des fichiers JAR imbriqués.
Cela n'affecte pas la plupart des utilisateursde Spring® Boot, sauf s'ils implémentent explicitement une logique de validation de signature numérique personnalisée pour les fichiers JAR imbriqués.
Pourquoi est-ce un problème ?
Spring® Boot regroupe les applications dans des fichiers JAR autonomes à l'aide de spring-boot-loader, qui comprend :
- Classes d'application(BOOT-INF/classes)
- Dépendances(BOOT-INF/lib sous forme de JARs imbriqués)
Si une organisation tente de vérifier les signatures numériques sur ces JAR imbriqués (par exemple, pour vérifier l'absence de falsification ou la confiance), la vérification peut réussir silencieusement même si :
- Le JAR imbriqué a été modifié
- La signature a été créée par un signataire inattendu ou malveillant
Pourquoi ? Parce que :
- Le modèle de signature du JAR Java n'a pas été conçu pour les JAR imbriqués.
- spring-boot-loader extrait et charge des JAR sans préserver le contexte de vérification de la signature d'origine
Impact dans le monde réel
- Répartition de la confiance dans la chaîne d'approvisionnement
- Vous pensez que vous ne chargez que des dépendances fiables (par exemple, signées par votre fournisseur), mais un pirate pourrait remplacer un JAR, et l'application pourrait faussement le signaler comme étant vérifié.
- Les outils de sécurité peuvent échouer
- La logique personnalisée, les scanners de sécurité ou les vérificateurs d'exécution utilisant les API JarFile peuvent valider de manière incorrecte le contenu imbriqué modifié.
- Menace interne ou risque de déploiement
- Un pipeline CI/CD compromis pourrait glisser des JAR altérés, sans que les contrôles de signature ne le détectent.
Exemple de scénario
- Une applicationSpring® Boot vérifie un fichier JAR imbriqué (par exemple, json-lib.jar) à l'aide de JarEntry.getCertificates(), en recherchant une signature fiable.
- Une version modifiée ou malveillante de json-lib.jar est fournie.
- Comme elles sont chargées via le chargeur de classes personnalisé deSpring® Boot, les API de signature Java renvoient une vérification réussie.
- L'application exécute un code non fiable, croyant qu'il est sûr.
Pourquoi c'est subtil mais dangereux
- La plupart des applications ne sont pas concernées car elles ne valident pas les signatures JAR.
- Mais dans les environnements sensibles en matière de sécurité (par exemple, les banques, la défense ou les marchés de fournisseurs), cela compromet les contrôles d'intégrité, ce qui peut entraîner l'exécution de codes ou la compromission de données.
Atténuation
Spring® Boot 2.7.x n'est plus pris en charge par la communauté open source, car sa date de fin de vie était le 30 juin 2023. Cela signifie simplement que les versions antérieures à cette date ne recevront aucune mise à jour pour résoudre ce problème.
Les utilisateurs des composants concernés doivent appliquer l'une des mesures d'atténuation suivantes :
- Tirez parti de l'Endless Lifecycle Support de TuxCare, qui prolonge le support de sécurité communautaire EoL, et appliquez simplement nos correctifs.
- Passez à la version 3.3.3+ de la communauté open source et acceptez le risque de ne plus recevoir de mises à jour de sécurité de la part de la communauté à partir du 30 juin 2025.
- Sinon, faites l'effort de passer aux dernières versions open source prises en charge du frameworkSpring® qui ne sont pas concernées, par exemple la version 3.4.x, et bénéficiez du soutien de la communauté jusqu'à fin 2025.
- Évitez de vous fier à la vérification des signatures pour les JAR imbriqués, sauf si vous utilisez des mécanismes d'empaquetage et de chargement fiables.
- Utiliser des outils de sécurité au niveau du système d'exploitation ou des vérificateurs externes pour l'intégrité des JAR.
Avez-vous besoin d'un correctif pour cette vulnérabilité pour une autre version du frameworkSpring®? Si oui, n'hésitez pas à nous contacter, nous sommes là pour vous aider !
Support technique
Documentation
Connexion
Nous contacter
