Grâce à une analyse de sécurité complète menée par l'équipe rouge d'OPSWAT, les chercheurs en sécurité Thai Do et Minh Pham ont identifié de multiples vulnérabilités affectant le cadre Rack Ruby, en particulier CVE-2025-25184, CVE-2025-27111, et CVE-2025-27610.
Cet article fournit une vue d'ensemble détaillée de ces vulnérabilités, avec un accent particulier sur CVE-2025-27610. Il examine les causes profondes, évalue les impacts potentiels et présente des stratégies d'atténuation efficaces pour sécuriser les applications reposant sur le framework Rack.
Vue d'ensemble du rack
Rack est une interface modulaire qui relie les serveurs web aux applications web basées sur Ruby. Elle standardise l'interaction entre ces composants en enveloppant les requêtes et les réponses HTTP dans un appel de méthode unique, ce qui simplifie le processus de développement et favorise la compatibilité entre différents cadres et serveurs.
Rack est utilisé par de nombreux frameworks et bibliothèques web Ruby, tels que Ruby on Rails et Sinatra. Il est disponible sous la forme d'une gemme Ruby. L'adoption généralisée de Rack, avec plus d'un milliard de téléchargements dans le monde, souligne son rôle essentiel dans l'écosystème de développement Ruby. Des composants intermédiaires tels que Rack::Static et Rack::Sendfile améliorent l'efficacité en gérant la livraison de contenu statique et en optimisant la transmission de fichiers. En raison de cette intégration poussée, les vulnérabilités découvertes dans Rack présentent des implications importantes en matière de sécurité, pouvant affecter de nombreuses applications et de nombreux systèmes dans le monde entier.
Découverte des vulnérabilités de sécurité dans le rack
Au cours d'une récente recherche sur la sécurité menée sur le cadre middleware Rack, les chercheurs d'OPSWAT Thai Do et Minh Pham ont identifié plusieurs vulnérabilités qui posent des risques de sécurité importants pour les applications web basées sur Ruby :
- CVE-2025-25184 : Thai Do a découvert une vulnérabilité permettant aux attaquants d'effectuer une injection de journal via les caractères CRLF (Carriage Return Line Feed), ce qui permet de manipuler les entrées de journal.
- CVE-2025-27111 : Minh Pham a découvert une faille de sécurité qui permet aux attaquants d'injecter et de manipuler le contenu du journal par le biais de valeurs d'en-tête malveillantes.
- CVE-2025-27610 : Minh Pham a également identifié une vulnérabilité de type Path Traversal, qui pourrait permettre à des attaquants d'obtenir un accès non autorisé à des fichiers situés en dehors du répertoire de fichiers statiques désigné, ce qui constitue une menace importante pour la sécurité.
Parmi ces vulnérabilités, la CVE-2025-27610 est particulièrement grave, car elle pourrait permettre à des attaquants non authentifiés de récupérer des informations sensibles, notamment des fichiers de configuration, des informations d'identification et des données confidentielles, ce qui entraînerait des violations de données. Cette vulnérabilité a reçu un score CVSS de 7,5, ce qui la classe dans la catégorie des risques de haute sévérité.
Vulnérabilité d'inclusion de fichiers locaux dans Rack::Static
Comprendre Rack::Static
Rack::Static est un intergiciel essentiel dans les applications Rack, utilisé principalement pour servir efficacement des fichiers statiques tels que JavaScript, CSS et images. En exploitant Rack::Static, les développeurs peuvent intégrer de manière transparente le service de contenu statique dans les applications Ruby sans avoir à s'appuyer sur une configuration supplémentaire du serveur web.
Lors de la configuration de Rack::Static, deux options essentielles se distinguent : :urls et :root. La compréhension et l'utilisation correctes de ces options simplifient et rationalisent considérablement le processus de distribution des fichiers statiques.
1. L'option :urls
L'option :urls spécifie les chemins d'accès URL que l'application Rack doit traiter comme des ressources statiques. Elle est fournie sous la forme d'un tableau de chaînes, chacune représentant un préfixe de chemin qui déclenche la gestion des fichiers statiques.
Par exemple :
Dans cette configuration, les requêtes vers /images, /css, ou /js sont interceptées et traitées par Rack::Static. Tout fichier correspondant à ces chemins sera directement servi à partir du système de fichiers.
2. L'option :root
L'option :root définit le répertoire de base à partir duquel les fichiers statiques seront servis. Ce répertoire est relatif au répertoire de travail actuel de votre application Rack.
Compte tenu de l'exemple précédent :
Lorsqu'une requête est adressée à /assets/logo.png, Rack::Static tente de servir le fichier situé à l'adresse public/assets/logo.png.
Exemple pratique
Une implémentation efficace de Rack::Static à travers les options :urls et :root fournit une méthode organisée et performante pour servir du contenu statique dans les applications web Ruby :
Dans ce scénario, les requêtes vers /assets/* et /favicon.ico seront automatiquement traitées par Rack::Static. Tous les fichiers correspondants doivent exister dans le répertoire public/assets et public/favicon.ico respectivement.
CVE-2025-27610 Détail technique
Au cours d'une analyse de sécurité approfondie de Rack::Static, Minh Pham a découvert une vulnérabilité importante liée à une mauvaise gestion de l'option :root. Spécifiquement, lorsque le paramètre :root n'est pas explicitement défini, Rack lui attribue par défaut la valeur Dir.pwd au répertoire de travail courant, le désignant implicitement comme le répertoire web racine de l'application Rack.
De manière significative, Rack::Static concatène directement les chemins d'URL entrants avec le répertoire :root spécifié sans validation ou assainissement suffisant. Par conséquent, si l'option :root n'est pas définie ou est mal configurée par rapport à l'option :urls, un attaquant non authentifié peut exploiter cette vulnérabilité en utilisant des techniques de traversée de chemin pour accéder à des fichiers sensibles en dehors du répertoire web prévu.
La section suivante fournit une analyse détaillée du processus de traitement des requêtes de Rack::Static, illustrant clairement comment cette vulnérabilité peut être exploitée.
Traversée de chemin et vulnérabilité d'inclusion de fichier local dans Rack::Static
Pour mieux comprendre comment l'intergiciel Rack::Static traite les requêtes, Minh Pham a procédé à une analyse approfondie du code source de Rack. Lors de l'initialisation de la classe Rack::Static, il a observé que si l'option :root n'est pas explicitement définie, Rack::Static sert par défaut les fichiers du répertoire de travail actuel (Dir.pwd). Par conséquent, si cette option n'est pas définie, l'intergiciel utilise implicitement le répertoire à partir duquel l'application est exécutée.
Après l'initialisation, il a été déterminé que lorsque Rack::Static reçoit une requête HTTP entrante, la méthode call est invoquée.
Ensuite, Rack::Static délègue l'opération de service de fichier à Rack::Files, qui tente de localiser et de servir le fichier en fonction du chemin d'accès construit à partir du répertoire :root configuré et du PATH_INFO fourni par l'utilisateur.
Tout d'abord, en invoquant les méthodes can_serve(path) et overwrite_file_path(path), l'intergiciel examine le fichier env["PATH_INFO"] pour déterminer si la requête entrante correspond à l'un des préfixes URL configurés (par exemple, /static, /public).
Si la condition est remplie, Rack::Static construit le chemin d'accès au fichier en combinant le répertoire racine configuré (:root) avec le PATH_INFO fourni par l'utilisateur. Cette construction s'effectue sans normalisation ni assainissement adéquats du chemin d'entrée. Spécifiquement, l'intergiciel concatène directement le PATH_INFO de la requête entrante avec le répertoire spécifié par l'option :root, introduisant une vulnérabilité due à une validation insuffisante du chemin fourni
Minh Pham a découvert qu'en raison de l'absence d'une vérification ou d'une validation appropriée dans ce flux de travail, si le PATH_INFO fourni par l'utilisateur contient des séquences de traversée de répertoire, et que l'option :root n'est pas explicitement définie, le chemin d'accès au fichier construit peut se résoudre à un emplacement en dehors du répertoire racine prévu, exposant potentiellement des fichiers sensibles.
CVE-2025-27610 Preuve de concept
Pour démontrer cette vulnérabilité dans Rack::Static, nous avons développé une application web basée sur Ruby utilisant la version 3.1.10 de Rack. Dans les scénarios où l'application ne définit pas explicitement l'option :root, un attaquant non authentifié peut exploiter cette vulnérabilité pour accéder à des données sensibles, telles que des informations d'identification, des fichiers de configuration ou des fichiers de base de données, ce qui peut conduire à une violation importante des données.
Veuillez vous référer à la vidéo suivante pour une démonstration détaillée de l'impact significatif associé à cette vulnérabilité :
Atténuation et orientation
Pour atténuer les vulnérabilités évoquées ci-dessus, veillez à ce que votre système soit mis à jour avec la dernière version de Rack.
MetaDefender Core utilisant le moteur SBOM peut détecter cette vulnérabilité.
OPSWAT MetaDefender CoreMetaDefender Core, équipé de fonctionnalités SBOMSoftware Bill of Materials) avancées, permet aux organisations d'adopter une approche proactive dans la gestion des risques de sécurité. En analysant les applications logicielles et leurs dépendances, MetaDefender Core identifie les vulnérabilités connues, telles que CVE-2025-27610, CVE-2025-27111 et CVE-2025-25184, dans les composants listés. Cela permet aux équipes de développement et de sécurité de donner la priorité aux correctifs, en atténuant les risques de sécurité potentiels avant qu'ils ne soient exploités par des acteurs malveillants.
Voici une capture d'écran des CVE-2025-27610, CVE-2025-27111 et CVE-2025-25184, qui ont été détectés par MetaDefender Core avec SBOM :
