Besu-Nutzer sollten jetzt handeln: Fünf Sicherheitslücken geschlossen

Der Ethereum-Client Besu hat fünf von der Sicherheitsfirma Certik entdeckte Schwachstellen behoben. Die betroffene Version 26.7.1 wurde bereits am 27. Juli als dringendes Sicherheitsupdate veröffentlicht, die technischen Details zu den Lücken folgten erst am 14. August – eine bewusste Verzögerung von 18 Tagen, die Node-Betreibern einen Vorsprung gegenüber potenziellen Angreifern verschaffen sollte.

Fünf Lücken, ein Patch-First-Ansatz

Certik entdeckte die Schwachstellen im Rahmen einer eigenständigen, nicht kundenfinanzierten Untersuchung auf einem privaten Multi-Node-Testnetzwerk. Die Forscher injizierten kontrollierte Fehler in Peer-to-Peer-, HTTP-RPC-, WebSocket-RPC- und konsensbezogene Schnittstellen und stießen dabei auf Probleme bei der Verarbeitung von Block-Ankündigungen, beim Puffern von Konsensvorschlägen für zukünftige Blöcke, bei WebSocket-Abonnementgrenzen sowie bei der Erstellung von JSON-RPC-Filtern.

Unbehoben hätten diese Lücken einem Angreifer erlaubt, Speicher oder Thread-Kapazität eines Knotens vollständig auszuschöpfen – mit direkten Folgen für Verfügbarkeit und Konsensverarbeitung. Certik stellte dem Besu-Team reproduzierbare Proof-of-Concept-Umgebungen zur Verfügung, sodass die Entwickler die Fehler vertraulich bewerten und beheben konnten, bevor Details öffentlich wurden.

Warum die zeitliche Lücke kein Zufall ist

Jialiang Chang, Director of Security Engineering und Senior Audit Partner bei Certik, verweist darauf, dass die Wirksamkeit des Modells aus der Abfolge der Schritte entsteht und nicht aus einer Verzögerung der Offenlegung um ihrer selbst willen. Besu habe die gepatchte Version Ende Juli bereitgestellt und klar kommuniziert, dass damit Sicherheitslücken behoben wurden, verbunden mit der Anweisung, so schnell wie möglich ein Upgrade durchzuführen.

Chang betont, dass dieser Ansatz Verteidigern einen begrenzten Vorsprung verschafft, bevor die genauen Angriffsmechanismen allgemein bekannt werden. Knotenbetreiber könnten das Zeitfenster nutzen, um betroffene Bereitstellungen zu identifizieren, exponierte Schnittstellen zu bewerten, die neue Version in einer Staging-Umgebung zu testen und Upgrades unter Validatoren zu koordinieren. Besonders relevant sei dies für institutionelle oder genehmigungsbasierte Blockchain-Netzwerke, in denen Upgrades formelle Change-Management-Protokolle erfordern.

Client-Diversität bleibt ein Dauerthema

Der Fall reiht sich in eine Serie von Vorfällen ein, die die Verwundbarkeit der Ethereum-Infrastruktur bei Client-Bugs zeigen. Erst kürzlich hatte ein schwerwiegender Fehler im Ausführungsclient Nethermind rund 8 Prozent der Ethereum-Validatoren betroffen und damit erneut die Risiken geringer Client-Diversität ins Bewusstsein gerückt. Ähnlich wie beim Umgang mit der jüngsten Coldcard-Firmware-Schwachstelle zeigt sich auch bei Besu, dass koordinierte Offenlegung und schnelle Patch-Zyklen zum Standard-Werkzeugkasten der Krypto-Sicherheitsbranche geworden sind.

Chang sieht die Open-Source-Community insgesamt auf dem Weg zu formalisierteren Sicherheitstests, verweist aber auf uneinheitliche Testabdeckung. Protokollkonformität und Zustandsübergänge seien oft besser abgesichert als kontinuierliche Tests auf Ressourcenerschöpfung, asynchrone Race-Conditions oder böswilliges Peer-Verhalten – genau jene Fehlerklasse, die bei Besu nun geschlossen wurde. Certik erweitert nach eigenen Angaben seine Chain-Scan-Methodik, um solche adversarischen Tests über mehrere Knoten hinweg dauerhaft fortzusetzen.

Relevanz für Node-Betreiber

Für Betreiber der Ethereum-Client-Infrastruktur ist die Meldung unmittelbar handlungsrelevant: Wer noch auf einer Version vor 26.7.1 läuft, sollte das Upgrade priorisieren, da die technischen Advisories inzwischen öffentlich einsehbar sind und damit auch potenziellen Angreifern zur Verfügung stehen. Für das breitere Ethereum-Ökosystem, dessen Vertrauensbasis auch institutionelle Nachfrage über Ethereum-ETFs stützt, bleibt robuste Node-Sicherheit ein Fundament, das selten Schlagzeilen macht, aber über die Stabilität des Netzwerks entscheidet.

Quelle: Certik Security Research