Bitcoin Core beendet sein einjähriges Embargo für Fehler, die sich mit einem einzigen KI-Prompt aufdecken lassen

Warum ein einjähriges Embargo nichts mehr bewirkte

Bitcoin Cores bisherige Richtlinie knüpfte den Zeitpunkt der Offenlegung an den Schweregrad. Fehler mit geringem Schweregrad wurden zwei Wochen nach Veröffentlichung des nächsten Hauptreleases öffentlich gemacht. Fehler mit mittlerem und hohem Schweregrad blieben privat, bis zwei Wochen nach dem Ende der Lebensdauer des letzten betroffenen Releases vergangen waren, ein Zeitraum, den die Richtlinie selbst als „ungefähr ein Jahr nach der ersten Veröffentlichung einer Hauptversion mit der Fehlerbehebung“ beschreibt.

Dieser Zeitplan hatte einen Grund. Bitcoin Core ist die Referenzimplementierung, auf der die Mehrheit der Bitcoin-Nodes läuft, und Node-Betreiber aktualisieren ihre Software nur langsam. Das lange Embargo sollte dem Netzwerk Zeit geben, Patches einzuspielen, bevor Einzelheiten öffentlich wurden. Der Nachteil war, dass Fehlerbehebungen im Allgemeinen nicht zurückportiert wurden. Betreiber älterer Releases mussten daher auf die nächste Hauptversion warten, die das Projekt ungefähr alle sechs Monate veröffentlichen will.

Die Vorsicht ist strukturell bedingt und kein Zufall. Konsensänderungen wie Bitcoins Taproot-Upgrade durchlaufen bewusst einen langsamen, konservativen Prozess, damit Betreiber sie in ihrem eigenen Tempo übernehmen können.

„Aufgrund der Art unseres Projekts und der zugleich langsamen Upgrade-Kultur sieht unsere Sicherheitsrichtlinie eine längere Embargoperiode vor“, schrieb Poinsot. „Das bedeutet im Allgemeinen, dass Sicherheitskorrekturen nicht zurückportiert werden können und Nutzern erst mit dem nächsten Hauptrelease zur Verfügung stehen.“

KI verändert diese Abwägung. Lässt sich ein Fehler mit einem trivialen LLM-Scan erneut entdecken, bringt es nichts, ihn zu verbergen, denn der Fehler ist bereits für alle greifbar, die einen Chatbot nutzen. „Bei diesen leicht auffindbaren Fehlern ist das die falsche Abwägung. Die Embargoperiode bewirkt kaum etwas, verzögert aber die Verfügbarkeit eines korrigierten Releases“, schrieb Poinsot.

Was sich durch die neue Kategorie „leicht auffindbar“ tatsächlich ändert

Mit der überarbeiteten Richtlinie gibt es nun eine dritte Einstellung für die Offenlegungsfrist. Bei der Untersuchung kann eine Schwachstelle als „leicht auffindbar“ eingestuft werden. Gemeint ist damit eine Schwachstelle, die sich „mit minimalem Aufwand entdecken lässt, etwa durch einen einfachen LLM-Prompt“. Die Einstufung beschränkt sich nicht auf Fehler, die von KI gefunden wurden: Entscheidend ist, wie wenig Aufwand die erneute Entdeckung erfordert, nicht, welches Werkzeug den Fehler gefunden hat.

Bei solchen Fehlern ändert sich das Vorgehen in jeder Hinsicht. Statt eine einzelne Fehlerbehebung in das nächste Hauptrelease aufzunehmen, werden die Maintainer sie auf jede derzeit unterstützte Hauptversion zurückportieren. Nach der Regel von Bitcoin Core, die jeweils drei neuesten Releases zu unterstützen, sind das drei Branches. Außerdem werden sie so schnell wie möglich Point-Releases veröffentlichen. Gleichzeitig mit der gepatchten Software erscheint ein Sicherheitshinweis.

Für alle anderen Fehler gilt weiterhin die Schweregrad-Einstufung. Fehler mit geringem Schweregrad bleiben beim Zweiwochenzeitplan. Bei Fehlern mit mittlerem und hohem Schweregrad gilt weiterhin die Frist von ungefähr einem Jahr. Kritische Fehler, also solche, mit denen Coins auf Protokollebene gestohlen, die Geldmenge erhöht oder die Chain dauerhaft aufgespalten werden könnte, bleiben von der Standardrichtlinie ausgenommen und werden wie bisher von Fall zu Fall behandelt.

Diese Ausnahme hat gute Gründe. In der Geschichte von Bitcoin Core war der im September 2018 als CVE-2018-17144 offengelegte Inflationsfehler ein Beispiel für eine Schwachstelle, die eine Sonderbehandlung rechtfertigte: Sie hätte die Erstellung von Coins außerhalb des Ausgabeplans ermöglichen können. Der neue Weg für „leicht auffindbare“ Fehler betrifft diese Kategorie nicht. Auf einen kritischen Fehler wird weiterhin ad hoc reagiert, wobei die Gefährdung des gesamten Netzwerks ausschlaggebend ist.

Zwei Wochen, ein Jahr oder „so schnell wie möglich“

Am einfachsten lässt sich die Änderung als Verkürzung der Offenlegungsfrist verstehen. Ein heute behobener Fehler mit mittlerem Schweregrad bliebe normalerweise etwa 52 Wochen lang privat und würde erst zwei Wochen nach dem Ende der Lebensdauer des letzten betroffenen Releases offengelegt. Wird derselbe Fehler als leicht auffindbar eingestuft, erscheint dafür ein Point-Release „so schnell wie möglich“ samt Sicherheitshinweis. Das ist der Unterschied zwischen einem Jahr und, nach der eigenen Beschreibung der Maintainer, der Zeit, die es braucht, einen gezielten Patch zu schreiben, zu prüfen und zu testen.

Die Zusage zum Zurückportieren ist die andere Hälfte der Änderung. Vorher erreichte eine Fehlerbehebung Nutzer älterer, weiterhin unterstützter Branches im Allgemeinen nicht, sondern kam mit dem nächsten Hauptrelease. Jetzt kann ein Betreiber einer älteren unterstützten Version ein gezieltes Point-Release installieren, ohne alle Funktions- und Verhaltensänderungen der neuesten Hauptversion übernehmen zu müssen. Für ein Netzwerk, in dem Upgrades langsam und bewusst vorgenommen werden, verändert das wesentlich, wie schnell ein Patch tatsächlich eingespielt werden kann.

Das Risiko, auf das die Maintainer selbst hingewiesen haben

Das schnellere Vorgehen hat seinen Preis, und Poinsot sprach ihn im Pull Request klar an. „Das ist besonders wichtig, weil Abhilfemaßnahmen nach dieser Richtlinie in Entwicklungs-Branches nicht so lange reifen können, bevor sie Nutzern zur Verfügung gestellt werden“, schrieb er. Eine Fehlerbehebung, die innerhalb weniger Tage veröffentlicht wird, verbringt weniger Zeit mit Prüfung und Tests als eine, die monatelang zurückgehalten wurde.

In der Diskussion gingen die Meinungen auch darüber auseinander, ob die Offenlegung noch schneller erfolgen sollte. Einige Mitwirkende argumentierten, dass schon das Öffnen eines Pull Requests für eine Fehlerbehebung Angreifer auf die Spur bringen könne, da sich das Repository leicht automatisch überwachen lasse. Daher müsse die Offenlegung spätestens mit dem Patch oder sogar davor, zusammen mit Hinweisen zu Abhilfemaßnahmen, erfolgen. Ein anderer Mitwirkender schlug vor, Fehlerbehebungen mit einem Hinweis nach Ermessen oder mit einem verzögerten Hinweis auszuliefern. Poinsot lehnte das ab und schrieb, dass eine Warnung ohne Einzelheiten bei Betreibern, die gar nicht betroffen waren, eine überstürzte Migration auslösen könnte.

Der Austausch ist wichtig, weil er zeigt, dass die neue Richtlinie ein bewusster Mittelweg und keine offensichtliche Lösung ist. Der zusammengeführte Text sieht vor, den Sicherheitshinweis gleichzeitig mit der Fehlerbehebung zu veröffentlichen und die vollständigen Einzelheiten statt einer vagen Warnung bereitzustellen.

Wenn die erste „leicht auffindbare“ Schwachstelle auftaucht

Bisher wurde noch keine Schwachstelle in die neue Klasse eingeordnet. Es handelt sich also um eine Änderung des Verfahrens, nicht um die Offenlegung einer aktuellen Schwachstelle. Der erste echte Test kommt, wenn die Verantwortlichen bei der Triage etwas als „leicht auffindbar“ einstufen und gleichzeitig Point-Releases für die gepflegten Branches mit einem Sicherheitshinweis veröffentlichen.

Das übergeordnete Signal ist, dass die KI-gestützte Suche nach Fehlern das Bitcoin-Ökosystem bereits zum Handeln gezwungen hat. Core Lightning riet Node-Betreibern Anfang dieses Jahres zu einem Upgrade oder zur Trennung vom Netzwerk, nachdem sich von KI erstellte Schwachstellenmeldungen als zutreffend erwiesen hatten. Die Richtlinienänderung bei Bitcoin Core zeigt, dass die Referenzimplementierung auf der Basisebene des Protokolls dieselbe Abwägung vornimmt: Wenn eine erneute Entdeckung günstig ist, bringt Geheimhaltung wenig, und ein langes Embargo verzögert nur die Veröffentlichung eines Fixes.

Für Node-Betreiber ändert sich heute nichts. Der Upgrade-Zyklus bleibt unverändert. Der Unterschied zeigt sich beim nächsten Fehler, der als leicht auffindbar eingestuft wird: Dann werden ein Patch und der dazugehörige Sicherheitshinweis gemeinsam veröffentlicht, mit weniger Vorlauf als je zuvor im Netzwerk.