Die Entwickler des XRP Ledger<\/strong> haben eine au\u00dfergew\u00f6hnliche Sicherheitsentscheidung getroffen, indem sie einen kritischen Protokollfehler behoben haben, ohne den \u00fcblichen zweit\u00e4gigen Genehmigungsprozess der Validatoren abzuwarten. Das Notfall-Update<\/strong>, das am 25. September<\/em> ver\u00f6ffentlicht wurde, beseitigte eine 11 Jahre alte Schwachstelle<\/strong>, die es Angreifern erm\u00f6glicht h\u00e4tte, XRP \u00fcber die beabsichtigte Versorgungsgrenze der Kryptow\u00e4hrung hinaus zu schaffen. Obwohl die Ermittler keine Hinweise auf eine Ausnutzung fanden, hat die Methode, die zur Behebung der Bedrohung verwendet wurde, eine Debatte dar\u00fcber ausgel\u00f6st, wie dezentrale Netzwerke in Notf\u00e4llen reagieren sollten.<\/p>\n Im Rahmen der normalen Governance des XRPL m\u00fcssen \u00c4nderungen, die die Transaktionsverarbeitung betreffen, die Unterst\u00fctzung von mehr als 80 %<\/strong> der vertrauensw\u00fcrdigen Validatoren f\u00fcr zwei aufeinanderfolgende Wochen erhalten, bevor sie aktiviert werden. Der Sicherheits-Patch vom September folgte jedoch einem anderen Verfahren. Laut dem offiziellen Schwachstellenbericht trat die Behebung sofort nach dem Upgrade auf xrpld 3.4.1<\/strong> auf jedem Server in Kraft, anstatt gleichzeitig durch eine genehmigte \u00c4nderung aktiviert zu werden. Die Entwickler erkl\u00e4rten, dass die Schwere der XRP-Versorgungsanf\u00e4lligkeit den normalen Prozess als zu riskant erscheinen lie\u00df. Die Ver\u00f6ffentlichung des Patches, w\u00e4hrend der Fehler w\u00e4hrend eines l\u00e4ngeren Abstimmungszeitraums ausnutzbar blieb, h\u00e4tte Angreifern gen\u00fcgend Informationen geben k\u00f6nnen, um den Exploit zu reproduzieren.<\/p>\n Das zugrunde liegende Problem betraf einen Integer-Overflow<\/strong> in der Zahlungsengine. Speziell konstruierte Transaktionen h\u00e4tten das System dazu bringen k\u00f6nnen, mehr XRP gutzuschreiben, als der Absender tats\u00e4chlich bezahlt hat, was potenziell zur Schaffung neuer Token h\u00e4tte f\u00fchren k\u00f6nnen. Forscher verfolgten den anf\u00e4lligen Code bis ins Jahr 2015<\/em> zur\u00fcck, fanden jedoch keine Hinweise darauf, dass er in einem \u00f6ffentlichen Netzwerk ausgenutzt wurde.<\/p>\n Die Entscheidung war nicht ohne technische Konsequenzen. Normalerweise aktivieren \u00c4nderungen gleichzeitig auf kompatiblen Servern, um sicherzustellen, dass Validatoren identische Transaktionsregeln anwenden. Das Notfall-Update schuf stattdessen einen vor\u00fcbergehenden Zeitraum, in dem aktualisierte Server bestimmte b\u00f6sartige Transaktionen ablehnten, w\u00e4hrend \u00e4ltere Versionen diese m\u00f6glicherweise weiterhin akzeptierten. Diese Uneinigkeit h\u00e4tte theoretisch die Ledger-Validierung unterbrochen, wenn Angreifer versucht h\u00e4tten, die Schwachstelle auszunutzen, bevor gen\u00fcgend Validatoren aktualisiert hatten. Allerdings reduzierte die schnelle Bereitstellung diese Exposition. Mehr als 80 %<\/strong> der Betreiber auf der Standard-Unique Node List hatten bis zum 25. September<\/em> Version 3.4.1<\/strong> installiert, so die Offenlegung des Entwicklungsteams.<\/p>\n Die Reaktion unterschied sich von der separaten Batch-Sicherheitsbehebung, die dem normalen \u00c4nderungsverfahren folgte und am 9. Oktober<\/em> aktiviert wurde. Der Vorfall hat Fragen dar\u00fcber aufgeworfen, wie viel Autorit\u00e4t Entwickler und Validatorenbetreiber w\u00e4hrend schwerwiegender Netzwerknotf\u00e4lle aus\u00fcben sollten. Die Kritik konzentrierte sich teilweise auf die vor\u00fcbergehende Verteilung von Software, bevor der sicherheitsrelevante Quellcode \u00f6ffentlich ver\u00f6ffentlicht wurde. Bef\u00fcrworter argumentieren, dass eine sofortige Koordination notwendig war, um zu verhindern, dass Angreifer eine offengelegte Schw\u00e4che ausnutzen.<\/p>\n Die XRPL Foundation hat Vorschl\u00e4ge zur\u00fcckgewiesen, dass Betreiber gezwungen wurden, das Update zu installieren, und betont, dass Validatoren ihre eigenen Upgrade-Entscheidungen getroffen haben. Die Debatte kommt auch auf, w\u00e4hrend bevorstehende XRPL-Darlehens-Upgrades weiterhin durch den normalen Abstimmungsprozess gehen, was zeigt, dass routinem\u00e4\u00dfige Protokoll\u00e4nderungen weiterhin nachhaltige Unterst\u00fctzung von Validatoren erfordern. Die Entwickler sind der Ansicht, dass das Umgehen von \u00c4nderungen f\u00fcr au\u00dfergew\u00f6hnlich schwerwiegende Sicherheitsbedrohungen reserviert bleiben sollte, anstatt eine Standardalternative zur Netzwerkgovernance zu werden.<\/p>\n F\u00fcr XRP-Inhaber wurde das unmittelbare Problem behoben: Die Schwachstelle wurde gepatcht, und die Ermittler berichteten von keiner bekannten Ausnutzung. Die langfristige Frage bleibt, wie XRPL die dezentrale Entscheidungsfindung aufrechterhalten kann, w\u00e4hrend es schnell genug auf zuk\u00fcnftige kritische Bedrohungen reagiert.<\/p>\n","protected":false},"excerpt":{"rendered":" Einf\u00fchrung Die Entwickler des XRP Ledger haben eine au\u00dfergew\u00f6hnliche Sicherheitsentscheidung getroffen, indem sie einen kritischen Protokollfehler behoben haben, ohne den \u00fcblichen zweit\u00e4gigen Genehmigungsprozess der Validatoren abzuwarten. Das Notfall-Update, das am 25. September ver\u00f6ffentlicht wurde, beseitigte eine 11 Jahre alte Schwachstelle, die es Angreifern erm\u00f6glicht h\u00e4tte, XRP \u00fcber die beabsichtigte Versorgungsgrenze der Kryptow\u00e4hrung hinaus zu schaffen. Obwohl die Ermittler keine Hinweise auf eine Ausnutzung fanden, hat die Methode, die zur Behebung der Bedrohung verwendet wurde, eine Debatte dar\u00fcber ausgel\u00f6st, wie dezentrale Netzwerke in Notf\u00e4llen reagieren sollten. Sicherheits-Patch und Governance Im Rahmen der normalen Governance des XRPL m\u00fcssen \u00c4nderungen, die die Transaktionsverarbeitung<\/p>\n","protected":false},"author":3,"featured_media":19446,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[64],"tags":[65,8,11117,872,11118],"class_list":["post-19447","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hack","tag-hack","tag-ripple","tag-validators","tag-xrpl","tag-xrpl-foundation"],"yoast_description":"Die Entwickler des XRP Ledger haben einen Notfall-Patch implementiert, um eine 11 Jahre alte Sicherheitsanf\u00e4lligkeit zu beheben, und umgingen aufgrund der Schwere der Bedrohung die \u00fcbliche Validatorenabstimmung.","_links":{"self":[{"href":"https:\/\/satoshibrother.com\/de\/wp-json\/wp\/v2\/posts\/19447","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/satoshibrother.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/satoshibrother.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/satoshibrother.com\/de\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/satoshibrother.com\/de\/wp-json\/wp\/v2\/comments?post=19447"}],"version-history":[{"count":0,"href":"https:\/\/satoshibrother.com\/de\/wp-json\/wp\/v2\/posts\/19447\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/satoshibrother.com\/de\/wp-json\/wp\/v2\/media\/19446"}],"wp:attachment":[{"href":"https:\/\/satoshibrother.com\/de\/wp-json\/wp\/v2\/media?parent=19447"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/satoshibrother.com\/de\/wp-json\/wp\/v2\/categories?post=19447"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/satoshibrother.com\/de\/wp-json\/wp\/v2\/tags?post=19447"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Sicherheits-Patch und Governance<\/h2>\n
Technische Details der Schwachstelle<\/h2>\n
Folgen der Entscheidung<\/h2>\n
Debatte \u00fcber Netzwerkgovernance<\/h2>\n
Schlussfolgerung<\/h2>\n