Le chercheur en sécurité Alvaro Muñoz a récemment mis en garde contre une vulnérabilité critique présente dans les versions 1,5 à 1,9 d’Apache Commons Text. La faille, baptisée « Text4Shell » et identifiée sous le numéro CVE-2022-42889, peut permettre l’exécution de code à distance via l’API StringSubstitutor. En réaction, la version 1.10 a été publiée ; elle désactive par défaut l’interpolation des scripts.
Bien que la faille affiche un niveau de gravité très élevé, de 9,8, et que son nom évoque une ressemblance avec le redouté Log4Shell , le chercheur de Rapid7 Erick Galinkin a estimé qu’il s’agissait d’une comparaison injuste. « La nature de la vulnérabilité signifie que, contrairement à Log4Shell, il sera rare qu’une application utilise le composant vulnérable de Commons Text pour traiter des données non fiables et potentiellement malveillantes », a-t-il écrit.
L’entreprise spécialisée dans la sécurité de WordPress Wordfence a détecté des acteurs malveillants à la recherche d’installations vulnérables, mais elle a reconnu que Text4Shell présentait un risque bien moindre que Log4j : « la bibliothèque Apache Commons Text est beaucoup moins largement utilisée de manière non sécurisée et la probabilité d’une exploitation réussie est nettement plus faible. »
Réagir à Text4Shell
Varun Badhwar, PDG et cofondateur d’Endor Labs, a déclaré que la vulnérabilité était préoccupante, mais pas surprenante. « Il est naturel et prévisible que les développeurs commettent des erreurs en écrivant du code, en particulier les mainteneurs et contributeurs de projets open source, pour qui ce travail n’est pas exercé à temps plein », a-t-il déclaré.
Selon Badhwar, le principal problème que Text4Shell posera à la plupart des entreprises est le temps nécessaire pour analyser et corriger le problème. « Avant tout, la plupart des organisations ne disposent pas des outils permettant de découvrir rapidement où cette dépendance est utilisée », a-t-il déclaré.
À ce titre, au moins, Badhwar estime que la comparaison avec Log4Shell est pertinente : le dernier rapport [PDF] du U.S. Cyber Safety Review Board consacré à Log4Shell indiquait qu’un ministère américain au niveau du cabinet avait consacré 33 000 heures à l’analyse de la faille et à la réponse à celle-ci.
« Même si nous espérons le meilleur de la part des mainteneurs, les utilisateurs finaux de logiciels open source doivent investir dans des solutions de gestion du cycle de vie des dépendances qui peuvent les aider à sélectionner les dépendances appropriées, à les sécuriser efficacement et à être prêts à analyser rapidement ce type d’incident et à y répondre avec un haut degré d’automatisation », a ajouté Badhwar.
Voir les meilleurs outils de débogage et de sécurité du code
Les dépendances des dépendances
Le chercheur en sécurité d’Endor Labs Henrik Plate a déclaré à eSecurity Planet que l’obscurité de la dépendance concernée constituait le principal défi. « Le problème général des vulnérabilités présentes dans les composants open source est que la majorité d’entre elles ne touchent pas directement les composants (dépendances) que les développeurs utilisent », a-t-il déclaré. « Elles touchent plutôt les dépendances de ces dépendances, ce qui rend très difficile pour le développeur de déterminer si une vulnérabilité donnée est réellement importante pour le logiciel qu’il développe. »
Dans le cas de Log4Shell, a expliqué Plate, la popularité de Log4j est au cœur de la menace, car « on peut littéralement le trouver partout ».
La situation est aggravée par le fait que la faille peut toucher des systèmes qui ne sont pas directement exposés à Internet. « Une chaîne de caractères ou un texte malveillant déclenchant la vulnérabilité pourrait être soumis par un attaquant à un système, puis transiter par différentes bases de données et différents systèmes jusqu’à exploiter un système vulnérable profondément enfoui dans le réseau d’une organisation », a-t-il déclaré.
« Log4j met en lumière le fait que, souvent, la charge liée à la réponse à une vulnérabilité largement répandue est plus dangereuse que la vulnérabilité elle-même », a ajouté Plate.
À lire également : Chaîne d’approvisionnement logicielle : une période à risque pour les dépendances
Gérer la surface d’attaque
Dans un récent billet de blog, Badhwar a indiqué que l’entreprise moyenne comptait plus de 40 000 dépendances open source téléchargées directement par les développeurs, chacune de ces dépendances entraînant en moyenne 77 autres dépendances. « Cela provoque une prolifération massive et incontrôlable, qui ralentit le développement tout en augmentant la surface d’attaque », a-t-il écrit.
De plus, les équipes de sécurité disposent souvent d’une visibilité très limitée sur l’endroit et la manière dont ce code est utilisé. Ainsi, lorsqu’une vulnérabilité est divulguée, déterminer si vous êtes concerné peut revenir à chercher une aiguille dans une botte de foin.
Plate a déclaré que la méthode de son entreprise pour répondre à ce type de problème était relativement unique. « La particularité d’Endor Labs est d’effectuer une analyse statique du code afin de vérifier si le fragment de code vulnérable contenu dans un composant open source peut être déclenché dans le contexte d’un logiciel donné, quelle que soit la profondeur à laquelle le composant vulnérable est dissimulé dans l’ensemble des dépendances », a-t-il déclaré.
« Ces informations contextuelles sont essentielles pour établir des priorités parmi les dizaines de vulnérabilités divulguées chaque semaine, qui génèrent des centaines, voire des milliers d’alertes, dont beaucoup ne devraient pas être portées à l’attention du développeur au départ », a ajouté Plate.
Pour aller plus loin: