Nach zwei Wochen seit dem letzten globalen Ausfall war gestern das Content Delivery Network von Cloudflare, das etwa 20% des weltweiten Webtraffics abwickelt, für 25 Minuten teilweise nicht erreichbar. Während des Vorfalls endeten etwa ein Drittel der Anfragen über Cloudflare mit einer leeren Seite und dem Fehlercode 500. Diesmal war die Ursache ein seit Jahren unentdecktes Problem im Lua-Code, der im WAF (Web Application Firewall) zur Filterung von Datenverkehr verwendet wird, um schädliche Anfragen zu blockieren.
Um die Systeme der Kunden vor einer kritischen Schwachstelle (CVE-2025-55182) in den Serverkomponenten des React-Frameworks zu schützen, nachdem ein Exploit öffentlich wurde, implementierten die Ingenieure von Cloudflare Schutzmaßnahmen auf der WAF-Ebene. Die Einführung des Schutzes verlief jedoch nicht reibungslos: Während der Implementierung wurde die Puffergröße zur Überprüfung des Traffics im Proxy erhöht,Servern, stellte sich jedoch heraus, dass das zur Testung verwendete WAF-Tool den festgelegten Puffer nicht unterstützt. Da dieses Tool keinen Einfluss auf den Datenverkehr hat, wurde beschlossen, es abzuschalten.
Um die Systeme abzuschalten, nutzten die Ingenieure das Subsystem "killswitch", um die Konfiguration schnell zu ändern und bestimmte Lua-Handler auf den Proxy-Servern ohne Änderung der Regeln zu deaktivieren. Diese Methode zur Deaktivierung von Regeln wird gelegentlich angewendet, um Fehler rasch zu beheben, was jedoch dazu führen kann, dass Teile des Lua-Codes nicht ausgeführt werden. Dabei wurde von den Ingenieuren nicht berücksichtigt, dass für den Aufruf des deaktivierten Test-Tools in den Lua-Regeln die Methode "execute" verwendet wurde, die einen zusätzlichen Satz von Regeln auslöst. Zuvor war der "killswitch"-Modus nie bei Regeln angewendet worden, die einen "execute"-Aufruf enthielten, und diese Kombination wurde nicht getestet.
Die Anwendung des «killswitch» führte dazu, dass der Code zur Definition einer zusätzlichen Testregelmenge deaktiviert wurde, der Aufruf dieser Regelmenge über «execute» jedoch blieb. Im Code gab es keine zusätzlichen Überprüfungen auf die Existenz des Objekts, und es wurde davon ausgegangen, dass bei Vorhandensein der Handlung «execute» in der Regelmenge das Objekt «rule_result.execute» unbedingt existiert. Infolgedessen gab es einen Versuch, die Methode «execute» für ein nicht initialisiertes Objekt aufzurufen, was zum Absturz des Handlers mit dem Fehler «attempt to index field ‘execute’ (a nil value)» führte. if rule_result.action == «execute» then rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)] end
Quelle: opennet.ru
