Déni de service par expression régulière dans websocket-extensions

Bienvenue dans la toute nouvelle série d’articles du blog Snyk ! Chaque mois, Snyk revient sur les vulnérabilités découvertes par notre équipe de recherche ou qui lui ont été signalées . Nous sélectionnons une vulnérabilité marquante du mois écoulé et racontons son histoire : sa découverte, les recherches menées et sa divulgation. Nous mettons à l’honneur les chercheurs, développeurs et utilisateurs qui contribuent à identifier et à corriger les vulnérabilités dans la communauté open source.

Nous lançons ce mois-ci cette série mensuelle avec une vulnérabilité découverte dans le package websocket-extensions.

Vulnérabilité : ReDoS dans websocket-extensionsCVE attribués :CVE-2020-7662, CVE-2020-7663Analyste Snyk :Sam SanoopDécouverte par : Robert McLaughlin

Le 2 juin 2020, l’équipe de recherche en sécurité de Snyk a publié une vulnérabilité de déni de service par expression régulière (ReDoS) détectée dans le très populaire package websocket-extensions, qui affectait plus de 13 000 projets analysés par Snyk. Robert McLaughlin, doctorant en informatique à l’Université de Californie à Santa Barbara, a signalé cette vulnérabilité à Snyk. Robert travaille au SecLab de l’UCSB et s’intéresse à la « détection et à la correction automatisées des vulnérabilités de sécurité dans les logiciels ». Il étudiait les vulnérabilités ReDoS dans l’écosystème Node.js lorsqu’il a découvert le problème.

Il nous a expliqué avoir découvert la vulnérabilité après avoir recueilli un grand échantillon d’expressions régulières provenant de packages npm populaires. L’équipe du laboratoire a utilisé des outils d’analyse ReDoS pour examiner les échantillons collectés. La vulnérabilité en question a finalement été identifiée grâce à l’outil open source RegexStaticAnalysis, publié et maintenu par Nicolaas Weideman.

La vulnérabilité identifiée pouvait permettre à un utilisateur malveillant d’attaquer l’algorithme d’expression régulière. En fournissant une entrée spécialement conçue, l’attaquant peut provoquer un phénomène appelé « retour arrière catastrophique » (catastrophic backtracking), dans lequel le moteur d’expressions régulières doit analyser un grand nombre de chemins possibles pour déterminer si la chaîne correspond au motif RegEx. Pour en savoir plus sur les vulnérabilités ReDoS, consultez cet article de blog.

Source : rapport Snyk State of Open Source Security 2019

En parallèle de ses recherches, Robert a développé un exploit de preuve de concept qu’il nous a fourni lorsqu’il a signalé la vulnérabilité. Sam Sanoop, analyste au sein de l’équipe de sécurité Snyk, a été chargé de vérifier que la vulnérabilité pouvait être reproduite. Cependant, Sam n’a pas réussi à reproduire l’exploit dans un conteneur de test à l’aide de la preuve de concept fournie. Robert a ensuite donné à Sam des instructions supplémentaires sur la manière de lancer l’exploit. Après avoir clarifié certains détails de la charge utile de l’attaque, Sam a pu confirmer que la vulnérabilité était bien reproductible.

Mais Sam ne s’est pas contenté de confirmer la présence de code vulnérable : il a également vérifié que, dans le contexte d’utilisation prévu du package, il s’agissait bien d’une vulnérabilité nécessitant une correction. Cette étape est particulièrement importante pour les vulnérabilités ReDoS. De nombreux motifs RegEx utilisés dans du code open source peuvent sembler vulnérables à première vue, mais ne sont en réalité pas exploitables.

Après avoir confirmé la validité, l’impact et la gravité de la vulnérabilité, Sam a examiné le code source du package. Il a localisé la ligne de code à l’origine de la vulnérabilité et formulé des recommandations pour corriger le problème précis qu’il avait repéré. Fort de ces informations, Sam a attribué deux CVE décrivant la vulnérabilité dans les versions JavaScript et Ruby du package. Il a également contacté le déclarant pour confirmer que la vulnérabilité avait été vérifiée, lui communiquer les numéros CVE réservés et l’informer que Snyk allait prendre contact avec le responsable de la maintenance. Sam a ensuite contacté ce dernier pour lui fournir les détails de la vulnérabilité ainsi que des recommandations précises sur la manière de corriger le problème.

Dans ce cas, websocket-extensions est un package très activement maintenu et son responsable a réagi rapidement aux informations communiquées. Quelques heures plus tard, il a confirmé à Sam qu’il avait compris la vulnérabilité et qu’il travaillait à sa correction. Sam lui a communiqué les numéros CVE à mentionner dans la publication du correctif, et ils se sont mis d’accord sur une date de publication de la vulnérabilité. Le responsable a publié un correctif moins d’un jour après que Snyk l’a informé du problème, et les avis de sécurité ont été publiés le lendemain.

Cette vulnérabilité illustre parfaitement comment le processus de divulgation de Snyk aide les chercheurs à signaler leurs découvertes et à en obtenir la reconnaissance, tout en collaborant avec les responsables de la maintenance des projets open source. Robert, le chercheur qui a signalé cette vulnérabilité, nous a expliqué pourquoi il avait choisi de la divulguer par l’intermédiaire de Snyk :

« Mon principal objectif en divulguant une vulnérabilité est d’obtenir un CVE, et Snyk s’en charge très bien. J’apprécie également que Snyk contacte les responsables concernés et coordonne la mise en place d’un correctif. » - Robert McLaughlin

Snyk a pour objectif de vérifier la validité et l’exploitabilité des vulnérabilités, tout en accompagnant les responsables de la maintenance dans le cadre d’une divulgation responsable et en leur fournissant des recommandations détaillées pour les corriger. Pour en savoir plus sur cette vulnérabilité ou sur la manière de signaler une vulnérabilité découverte dans un projet open source, consultez les liens ci-dessous.

• Signaler une vulnérabilité

• Description de la vulnérabilité (JavaScript)

• Description de la vulnérabilité (Ruby)