Spring4Shell : faut-il comparer cette faille Java critique à Log4Shell ?

Clément Bohic,
Spring4Shell Log4j Log4Shell fondation Apache

Le cœur fonctionnel du framework Spring a fait l’objet d’un correctif pour une faille critique. Faut-il la comparer à Log4Shell, qui touchait un autre composant Java ?

Spring4Shell sèmera-t-elle autant de panique que Log4Shell ? La question se pose à propos de cette vulnérabilité découverte dans le cœur fonctionnel du framework Spring. Immatriculée CVE-2022-22965, elle est critique (score de base : 9,8 sur l’échelle CVSS 3).

Il y a parfois eu confusion, ces derniers jours, avec une autre faille révélée quasiment en parallèle. Critique également, et qui affecte aussi Spring, mais au niveau de la bibliothèque Cloud Function. Son matricule : CVE-2022-22963.

L’une et l’autre vulnérabilité ont le même effet potentiel : la prise de contrôle, à distance, d’un hôte ou d’un conteneur. Chacune a fait l’objet de correctifs… diffusés plus ou moins dans l’urgence. Pour la faille Cloud Function, l’entité qui pilote le développement du framework (Spring.io, filiale de VMware) a pu orchestrer la démarche comme elle le souhaitait. Pour l’autre faille, ça n’a pas été la même histoire : c’est l’apparition d’un PoC qui a donné l’alerte. Apparu brièvement le 29 mars, il a vite été reproduit. Son principe : injecter une commande curl modifiant les propriétés de journalisation d’un serveur Tomcat afin de pouvoir écrire des données dans des emplacements sensibles. Plus précisément, à la racine, un fichier JSP (JavaServer Pages) contenant un webshell.

Un temps, on a supposé que cette vulnérabilité avait été introduite avec un patch – qui éliminait un risque d’exécution de code à distance dans une fonction de clonage d’exceptions. Spring.io a démenti tout lien dans son annonce anticipée (publiée avant l’attribution d’une CVE).

Spring4Shell : plus « spécifique » que Log4Shell ?

Que retenir de cette annonce ? En premier lieu, que la faille affecte toutes les versions de Spring Core encore prises en charge, sur les branches 5.2 et 5.3 ; ainsi que les plus anciennes. Les correctifs sont intégrés à partir des versions 5.2.20 et 5.3.18. Ainsi qu’à partir des versions 2.5.12 et 2.6.6 de Spring Boot.

Alors que Log4Shell touchait des configurations par défaut de la bibliothèque Log4j, Spring4Shell ne fonctionne que sous certaines conditions. Rapid7 les résume ainsi :

– Les applications MVC et WebFlux exploitant JDK 9 ou toute version ultérieure ont des chances d’être vulnérables

– Encore plus de chances pour les applications qui, en plus, utilisent l’annotation @RequestMapping avec des paramètres de type POJO (Plain Old Java Object)

– Et encore plus de chances si elles utilisent Tomcat

Les apps déployées au format par défaut (JAR) semblent résister à la faille ; au contraire de celles empaquetées en WAR.

Nombre d’indicateurs témoignent d’une exploitation active de la faille.

Même chose pour la CVE-2022-22963, qui a elle aussi son lot de PoC. Pour la juguler, on installera si possible la version 3.1.7 ou 3.2.3 de la bibliothèque Cloud Function. À défaut, on pourra notamment passer à une version de JDK antérieure à la 9.

Photo d'illustration © monsitj - Adobe Stock