Protobuf JS expose les systèmes à la vulnérabilité d'exécution de code à distance

Une vulnérabilité critique de l'exécution de code à distance (ERC) est apparue dans protobub.js, l'implémentation JavaScript des tampons Protocole qui utilisent des milliers de projets sur Node.js. Le problème a attiré l'attention après que les chercheurs ont partagé une preuve publique de concept et les responsables ont publié des correctifs; étant donné la popularité de la librairie - qui enregistre près de 50 millions de téléchargements par semaine- la découverte mérite une attention immédiate de la part des équipes de développement et des opérations.

L'échec réside dans la manière dont la librairie génère le code dynamiquement à partir des schémas. Au lieu de construire des structures sécurisées, protobub.js concaténe chaînes pour former des fonctions JavaScript et les exécuter avec le constructeur Function (), appliquant très peu ou pas de validation sur les identifiants extraits du schéma (noms de message, types, etc.). Un schéma manipulé par un attaquant peut insérer du code malveillant dans cette chaîne, de sorte que lorsque la fonction synthétique est finalement évaluée, le code injecté est exécuté dans le contexte du processus qui charge le schéma.

Ce vecteur transforme un schéma malveillant en une porte d'accès aux variables d'environnement, secrets, connexions de base de données et autres ressources internes; il permet également des mouvements latéraux si l'application est déployée dans une infrastructure partagée. Ce n'est pas seulement un risque pour les serveurs : si les développeurs chargent et décodent des schémas peu fiables sur leurs machines locales, leur environnement de travail peut également être compromis.

Le problème a été découvert par le chercheur Cristian Staicu et documenté par la société de sécurité Endor Labs dans un rapport détaillé; la vulnérabilité est enregistrée dans GitHub comme SGHA-xq3m-2v4x-88gg et Endor Labs explique le mécanisme et montre un PoC dans son analyse ( rapport de Endor Labs). Bien que les auteurs du rapport aient noté que l'exploitation est simple Pour l'instant, aucune activité malveillante généralisée n'a été confirmée dans les environnements de production.

La vulnérabilité affecte les versions de protobub.js avant ou après 8.0.0 et 7.5.4. Les responsables ont publié des corrections qui sont disponibles dans les branches principales: la série 8.x a été corrigée avec la version 8.0.1 et la série 7.x avec la 7.5.5; les paquets npm avec les correctifs ont été publiés en avril (mises à jour pour 8.x et 7.x à différentes dates). Les notes de dépôt et de sécurité se trouvent sur la page du projet dans GitHub: protobub.js à GitHub et leurs rejets.

La solution urgente appliquée au patch est de désinfecter les noms de type, en éliminant les caractères non alphanumériques pour empêcher un attaquant de fermer la fonction synthétique et d'ajouter des instructions malveillantes. Cependant, les experts soulignent qu'une correction plus robuste va au-delà de l'utilisation complète de la génération dynamique de code avec la fonction () pour traiter des identifiants qui peuvent provenir de sources externes : éviter le "trippage" des identifiants par le biais du code généré est une réparation de conception plus sûre et durable.

Si votre projet dépend de protobub.js, agissez maintenant: mise à jour des versions parchées, contrôle le graphique des dépendances pour les versions vulnérables (même les dépendances transitoires) et traite le chargement des schémas comme une entrée peu fiable. Pour les équipements de production, une pratique recommandée consiste à utiliser des schémas précompilés ou statiques plutôt que de générer et d'évaluer du code dans le temps de fonctionnement. Endor Labs suggère également d'auditionner les dépendances transitoires et d'examiner les pipelines CI/CD qui peuvent introduire des schémas non vérifiés.

En termes pratiques, vous pouvez vérifier quelle version est installée avec les commandes du gestionnaire de paquets (par exemple en inspectant package.json ou en utilisant des outils comme npm ls) et forcer les mises à jour vers des versions sécurisées (par exemple npm installe protobujs @ ^ 8.0.1 ou version 7.5.5 selon la branche que vous utilisez). En outre, il est recommandé d'intégrer des scans automatiques de logiciels dans le pipeline et les politiques qui empêchent le téléchargement et l'exécution de schémas d'origine non contrôlée.

La divulgation publique a inclus un PE dans les propres conseils de sécurité du projet, ce qui permet aux équipes techniques de reproduire le problème pour le valider dans des environnements contrôlés; les conseils officiels à GitHub contiennent le lien avec cet exemple et la discussion technique ( conseil en GitHub). Si vous avez besoin de plus de contexte sur la recherche et les recommandations techniques, l'analyse d'Endor Labs est bien documentée et mérite d'être lu attentivement: rapport de Endor Labs.

La leçon pour la communauté du développement est double: d'une part, la grande commodité de générer du code entraîne des risques dynamiques lorsque les entrées ne sont pas bien validées; d'autre part, la dépendance énorme à l'égard des bibliothèques partagées fait qu'une seule vulnérabilité peut être étendue. Mise à jour, audit et réduction de la surface d'exposition reste la meilleure défense.