La base de données H2 présente une vulnérabilité critique à la Log4Shell

Par:
fredericmazue

lun, 10/01/2022 - 17:12

Alors que la vulnérabilité Log4Shell de Log4j n'a pas fini de défrayer le chronique, voici que les chercheurs en sécurité de JFrog ont découvert une vulnérabilité dans la base de données H2. Une vulnérabilité qui ressemble beaucoup à Log4Shell.

Pour mémoire, H2 est un système de gestion de base de données relationnelles écrit en Java. Il peut être intégré à une application Java ou bien fonctionner en mode client-serveur. Son fichier jar est petit : environ 1 Mo. H2 est une solution de stockage de données populaire pour divers projets, des plates-formes Web telles que Spring Boot aux plates-formes IoT telles que ThingWorks. Le package com.h2database:h2 fait partie des 50 packages Maven les plus populaires, avec près de 7 000 dépendances d'artefacts, souligne JFrog.

La vulnérabilité découverte est estampillée CVE-2021-42392. Le bulletin de sécurité indique : La méthode org.h2.util.JdbcUtils.getConnection de la base de données H2 prend en paramètres le nom de classe du driver et l'URL de la base de données. Un attaquant peut passer un nom de pilote JNDI et une URL menant à un serveur LDAP ou RMI, provoquant l'exécution de code à distance. Cela peut être exploité via divers vecteurs d'attaque, notamment via la console H2 qui conduit à l'exécution de code à distance non authentifié.

Cette vulnérabilité à la Log4Shell est toutefois moins grave, car ainsi que l'expliquent les experts de JFrog, contrairement à Log4Shell, cette vulnérabilité a une portée d'impact « directe ». Cela signifie que généralement le serveur qui traite la demande initiale (la console H2) sera le serveur qui sera impacté par RCE. C'est moins sévère par rapport à Log4Shell car les serveurs vulnérables devraient être plus faciles à trouver. Par ailleurs, la console de H2 n'écoute par défaut que les connexions localhost tandis que Log4Shell était exploitable dans la configuration par défaut de Log4j. Enfin, de nombreux fournisseurs peuvent exécuter la base de données H2, mais pas la console H2. Bien qu'il existe d'autres vecteurs pour exploiter ce problème autres que la console, ces autres vecteurs dépendent du contexte et sont moins susceptibles d'être exposés à des attaquants distants.

Il est imprudent de se croire à l'abri de cette vulnérabilité, les chercheurs soulignent : si vous exécutez une console H2 qui est exposée à votre LAN (ou pire, WAN), ce problème est extrêmement critique (exécution de code à distance non authentifié) et vous devez mettre à jour votre base de données H2 vers la version 2.0.206 immédiatement, tout en ajoutant que de nombreux outils de développement s'appuient sur la base de données H2 et exposent spécifiquement la console H2. Nous renvoyons le lecteur au billet pour lequel un lien est donné au début de cet article pour plus d'informations.