Deux semaines après la dernière panne mondiale, hier, le réseau de diffusion de contenu Cloudflare, qui gère environ 20 % du trafic web mondial, a été partiellement inaccessible pendant 25 minutes. Pendant l'incident, environ un tiers des requêtes via Cloudflare se sont terminées par un retour de page vide avec un code d'erreur 500. Cette fois, la cause était un problème de longue date dans le code Lua utilisé dans le système de filtrage de trafic WAF (Web Application Firewall) pour bloquer les requêtes malveillantes.
Pour protéger les systèmes des clients contre une vulnérabilité critique (CVE-2025-55182) dans les composants serveur du framework React, après la publication d'un exploit, les ingénieurs de Cloudflare ont mis en place une protection au niveau du WAF. Cependant, l'implémentation de cette protection ne s'est pas déroulée sans accrocs : pendant l'intégration, la taille du tampon pour vérifier le trafic sur le proxy a été augmentée,serveurs, mais il s'est avéré que l'outil de test utilisé pour le WAF ne prend pas en charge la taille du tampon définie. Comme cet outil n'affecte pas le trafic, il a été décidé de le désactiver.
Pour désactiver cet outil, les ingénieurs ont utilisé le sous-système « killswitch » pour modifier rapidement la configuration et désactiver certains gestionnaires Lua sur les serveurs proxy sans remplacer les règles. Cette méthode de désactivation des règles est parfois utilisée pour corriger rapidement les erreurs et entraîne l'omission de l'exécution d'une partie du code Lua. Cependant, les ingénieurs n'ont pas pris en compte que pour appeler l'outil de test désactivé dans les règles Lua, la méthode « execute » était utilisée, déclenchant un ensemble supplémentaire de règles. Auparavant, le mode « killswitch » n'avait jamais été utilisé avec des règles contenant un appel à « execute », et cette combinaison n'a pas été testée.
L'utilisation du « killswitch » a entraîné la désactivation du code définissant un ensemble de règles de test supplémentaires, mais l'appel de cet ensemble de règles via « execute » est resté. Dans le code, il n'y avait pas de vérifications supplémentaires de l'existence de l'objet, et il était supposé que si l'ensemble de règles contenait l'action « execute », l'objet « rule_result.execute » devait absolument exister. En conséquence, une tentative d'exécution de la méthode « execute » sur un objet non initialisé a entraîné l'arrêt anormal du gestionnaire avec l'erreur « attempt to index field ‘execute’ (a nil value) ». if rule_result.action == « execute » then rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)] end
Source : opennet.ru
