On est là en train de chiller dans une bonne journée bien normale quand SOUDAIN alerte rouge internationale, on apprend qu’il y a une faille critique CVSS 10 dans Apache Parquet, et que tout le monde panique bien évidemment !!
Vous, admin système ou développeur, vous vous précipitez sur votre téléphone qui n’arrête pas de sonner pendant que les experts du CERT vous bombardent de mails d’alerte… et au milieu de ce chaos, vous vous grattez la tête (ou autre chose) en vous demandant : “Mais est-ce que je suis vraiment concerné, ou c’est encore une tempête dans un verre d’eau ?”
Et bien si vous êtes du genre à vouloir du concret plutôt que de la rumeur, cet article va vous aider à savoir de quoi il en retourne sur la faille CVE-2025-30065 qui a provoqué des sueurs froides à pas mal de monde ces derniers jours. C’est un cas d’ailleurs assez incroyable où une amélioration de sécurité est devenue une vulnérabilité critique.
Et bien sûr je vais vous montrer comment vérifier si vos systèmes sont vraiment vulnérables en quelques minutes, sans passer des heures à éplucher vos dépendances Maven.
Bref, Apache Parquet, pour ceux qui ne seraient pas familiers avec ce mot, c’est un format de stockage en colonnes particulièrement efficace pour le traitement analytique des données. Il est utilisé par l’écosystème Apache Hadoop et des milliers de projets open-source, notamment dans tout ce qui est pipelines de données, l’IA/ML et le big data. Par exemple, des boîtes comme Airbnb, Twitter ou Netflix l’utilisent quotidiennement pour gérer leurs monstrueuses quantités de données.
Maintenant ce qui est délire avec la CVE-2025-30065, c’est sa chronologie complètement WTF :
- 2 mai 2024 : Apache Avro ajoute une fonctionnalité de sécurité (pas de CVE)
- 5 août 2024 : La fonctionnalité est incluse dans Apache Avro 1.11.4
- 5 mars 2025 : Un développeur suggère d’ajouter la même fonctionnalité à Apache Parquet
- 16 mars 2025 : Apache Parquet 1.15.1 est publié avec la nouvelle fonctionnalité
- 29 mars 2025 : Des rumeurs sur une vulnérabilité grave commencent à circuler
- 1er avril 2025 : Annonce officielle de CVE-2025-30065 avec score CVSS 10.0 (et non, ce n’était pas un poisson d’avril !)
Et voilà comment une amélioration de sécurité (l’ajout d’une liste d’autorisation) est devenue une vulnérabilité critique.
Et le plus ironique là dedans c’est que Apache Avro a implémenté exactement la même chose sans recevoir de CVE. Il n’en a pas eu le temps puisque, le “correctif” était déjà disponible deux semaines avant l’annonce officielle. Oui, je vous avait dit que la chronologie des événements était Ouatzefuck !
Techniquement, la vulnérabilité se situe dans le module parquet-avro qui permet d’incorporer des objets Avro dans des fichiers Parquet. Pour les non-initiés, la désérialisation est le processus qui transforme des données stockées en objets utilisables par un programme. Le problème ici, c’est que lors de cette désérialisation, il est possible d’instancier des classes Java arbitraires.
Cependant, contrairement aux vulnérabilités classiques de désérialisation Java, seule l’instanciation via un constructeur avec un unique paramètre String est possible. Cette limitation réduit heureusement considérablement l’exploitabilité réelle de la faille, comme on va le voir.
Un score CVSS 10.0, c’est, comme vous le savez, le niveau maximum sur l’échelle de gravité des vulnérabilités. On parle généralement d’exécution de code à distance sans authentification, du genre Heartbleed (OpenSSL) ou Log4Shell qui ont mis internet à genoux il y a quelques années.
Mais dans le cas de la CVE-2025-30065, les limites réelles de l’exploitation sont beaucoup plus contraignantes qu’il n’y paraît car contrairement aux vulnérabilités classiques de désérialisation Java où on peut chaîner des “gadgets” (des objets Java utilisés comme pièces d’un puzzle malveillant) pour exécuter virtuellement n’importe quoi, ici l’attaquant est limité à l’instanciation de classes qui :
- Sont déjà dans le classpath de la cible
- Ont un constructeur acceptant un unique paramètre String
- Produisent des effets secondaires utiles lors de leur instanciation
Les scénarios d’attaque possibles restent donc limités :
- Watering hole : publier un dataset malveillant sur un dépôt public
- Ingénierie sociale : envoyer directement le fichier Parquet malveillant
- Spear-phishing : cibler des développeurs spécifiques
Dans tous les cas, l’attaquant doit avant tout convaincre sa victime de traiter un fichier Parquet malveillant, ce qui n’est pas toujours évident.
Alors pourquoi être quand même prudent ?
Et bien parce que Parquet est omniprésent dans les pipelines de données et l’IA/ML. Les configurations peuvent varier énormément d’un environnement à l’autre, et certaines organisations traitent des fichiers Parquet de sources externes non vérifiées. Le risque est donc significatif dans certains contextes, même s’il n’est pas universel.
Face à cette situation, F5 Labs a développé un petit outil génial : le “Canary Exploit”. Tel un courageux petit canari dans une mine qui détecte les gaz toxiques, cet outil open-source crée un fichier Parquet malveillant qui tente d’effectuer une requête HTTP vers une URL que vous lui indiquez. Si votre système est vulnérable, il va alors tenter de se connecter à cette URL, vous confirmant le problème.
Techniquement, l’outil génère un fichier Parquet contenant un schéma Avro spécial. Ce schéma indique que la chaîne de caractères doit être interprétée comme un objet javax.swing.JEditorPane. Ainsi lorsqu’un système vulnérable traite ce fichier, il instancie cette classe avec l’URL fournie, qui tente alors de se connecter, confirmant la vulnérabilité.
Voulez-vous vérifier si vous êtes vulnérable ?
Alors d’abord, assurez-vous d’avoir Java JDK 21+ installé sur votre machine et suivez les étapes suivantes sur le README du projet. Attention, chez moi, la commande curl n’a pas fonctionné alors j’ai du récupérer le .jar manuellement.
C’est simple d’utilisation, même si vous n’êtes pas un ninja en sécu et ça permet de vérifier rapidement si vos systèmes sont concernés. Et puis si vous avez mis en place le correctif, ça permet de vérifier qu’il est effectivement bien en place. C’est le genre d’outil qui permet de vérifier rapidement que tout est OK plutôt que de se palucher une vérif manuelle des dépendances Maven ou Gradle. Et ça fonctionne sous Linux, macOS et Windows.
Bien sûr, il y a quelques limitations :
- Votre système doit pouvoir effectuer des requêtes sortantes (HTTP/DNS)
- Des configurations réseau restrictives peuvent conduire à des faux négatifs
- Des configurations très spécifiques de SERIALIZABLE_PACKAGES pourraient aussi fausser les résultats
- Ce n’est pas un remplacement pour une analyse complète de sécurité
Mais franchement, pour un test rapide, c’est l’idéal.
Maintenant, qui devrait réellement s’inquiéter de ce truc ?
Et bien toutes les organisations utilisant Apache Parquet Java avec le module parquet-avro en versions ≤1.15.0, et particulièrement celles qui traitent des fichiers Parquet de sources externes. Les environnements ML/IA/Big Data où Parquet est couramment utilisé devraient également être vigilants.
Et si vous êtes vulnérables, pas de panique ! Voici les solutions pour vous protéger :
- Mettre à niveau vers Apache Parquet ≥1.15.1
- Configurer correctement org.apache.parquet.avro.SERIALIZABLE_PACKAGES pour restreindre les packages autorisés
- Éviter le paramètre générique « * » qui annule l’effet de la liste d’autorisation
- Analyser votre arbre de dépendances avec Maven ou Gradle pour détecter les versions vulnérables
Bref, c’est potentiellement dangereux dans certaines conditions très spécifiques, mais loin d’être le scénario catastrophe que le score CVSS 10.0 laisse imaginer. Quoiqu’il en soit, maintenant vous savez.
Source link
Subscribe to our email newsletter to get the latest posts delivered right to your email.
Comments