L’équipe de sécurité de Rust a corrigé un bogue dans la caisse regex qui laissait les applications ouvertes aux attaques par déni de service (DoS).
Si une chaîne d’expression régulière est trop complexe à analyser, elle consomme des ressources et ralentit les serveurs d’applications. Les attaquants profitent de cette caractéristique pour organiser des attaques par déni de service Regex (ReDoS) via des fonctionnalités d’application telles que des pages de recherche et des API.
Complexité de la compilation des regex
Les attaques ReDoS sont bien connues et documentées.
La plupart des langages informatiques, y compris Rust, ont des mesures défensives pour limiter la complexité des chaînes regex et empêcher les attaques ReDoS. Mais le bogue récemment découvert dans la bibliothèque regex de Rust a épuisé les ressources du serveur d’une manière qui n’était pas provisionnée dans les méthodes de défense par défaut.
« La plupart des ReDoS se produisent lorsqu’un attaquant prend le contrôle d’une entrée regex et est capable de charger des regex qui [will] soit remplir la mémoire, soit prendre beaucoup de temps à s’exécuter/compiler », a déclaré Addison Crump, le chercheur en sécurité qui a signalé le bogue. La gorgée quotidienne. « rust-lang/regex a des atténuations afin que les développeurs puissent autoriser les regexes non fiables et garantir une complexité temporelle linéaire pour empêcher le DoS et une surcharge de mémoire maximale.
CONSEILLÉ OpenSSL abandonne la mise à jour résolvant le problème DoS de « gravité élevée » dans la bibliothèque de chiffrement omniprésente
Crump a poursuivi: « Les entrées que j’ai découvertes ont permis une complexité temporelle exponentielle dans le processus de compilation des regex, ce qui a violé les garanties de sécurité de la caisse. »
Selon le validation de correctif, les sous-expressions regex vides avec de grandes répétitions évitaient de déclencher l’une des atténuations existantes, qui étaient orientées vers l’utilisation de la mémoire, et non vers le temps de compilation. Par conséquent, des expressions régulières soigneusement conçues pourraient amener le compilateur d’expressions régulières à tenter de générer une quantité croissante de sous-expressions vides.
Selon l’historique Git de la bibliothèque affectée, le bogue existait au moins depuis 2018, lorsque la syntaxe regex a été réécrite, selon Crump.
« La gravité de cette vulnérabilité est » élevée « lorsque la caisse » regex « est utilisée pour analyser les regex non fiables », a déclaré un consultatif par les États du Rust Security Response Workgroup.
Fuzzing sensible à la structure
Crump a découvert le bogue ReDoS en expérimentant le fuzzing de la caisse cargo-fuzz.
« Ce que j’ai fait, c’est de générer uniquement des regex valides (ou, du moins, uniquement des AST de regex valides) en utilisant Arbitraire pour générer des entrées structurées, puis le remettre sous sa forme de chaîne avant de l’exécuter contre regex », a expliqué Crump.
Cette approche est une rupture avec les méthodes de fuzzing traditionnelles qui génèrent beaucoup de sorties aléatoires, dont une grande partie est du bruit inutile.
« J’ai fait fonctionner le fuzzer pendant environ 20 secondes avant de commencer à remarquer des écarts étranges dans le temps d’exécution. J’ai mis un délai d’attente sur le fuzzer pour chaque cas de test et j’ai sorti l’une des variantes de regex qui pourraient être utilisées pour effectuer le DoS », a déclaré Crump.
Crump a recommandé aux développeurs Rust d’utiliser le fuzzing sensible à la structure pour découvrir la corruption potentielle de la mémoire et les bogues logiques dans leur code.
« Ce n’est pas parce que vous utilisez un langage qui est sûr pour la mémoire, prêt à l’emploi, que les plantages ou même la corruption des données ne seront pas introduits en ne réfléchissant pas à tous les cas possibles, et le fuzzing est un excellent moyen pour trouver ces cas », a conclu Crump. « Le fuzzing sensible à la structure en particulier vous permettra d’identifier les problèmes profonds dans le code afin que vous puissiez trouver des cas extrêmes auxquels vous, en tant qu’être humain, ne penseriez jamais. »
