Autor: CertiK
Zuvor hatte das CertiK-Team eine Reihe von Denial-of-Service-Schwachstellen in der Sui-Blockchain entdeckt. Unter diesen Schwachstellen sticht eine neue und schwerwiegende Schwachstelle hervor. Diese Schwachstelle kann dazu führen, dass Sui-Netzwerkknoten keine neuen Transaktionen verarbeiten können, was einer vollständigen Abschaltung des gesamten Netzwerks gleichkommt.
Erst letzten Montag erhielt CertiK eine SUI-Bug-Prämie in Höhe von 500.000 US-Dollar für die Entdeckung dieser großen Sicherheitslücke. CoinDesk, das maßgebliche Medium der US-Branche, berichtete über den Vorfall, und dann folgten große Medien seinem Bericht und veröffentlichten relevante Nachrichten.
Diese Sicherheitslücke wird anschaulich als „Hamsterrad“ bezeichnet: Ihre einzigartige Angriffsmethode unterscheidet sich von derzeit bekannten Angriffen. Der Angreifer muss nur eine Nutzlast von etwa 100 Bytes einreichen, um eine Endlosschleife im Sui-Verifizierungsknoten auszulösen um auf neue Transaktionen zu reagieren.
Darüber hinaus kann der durch den Angriff verursachte Schaden auch nach einem Neustart des Netzwerks bestehen bleiben und sich automatisch im Sui-Netzwerk ausbreiten, sodass alle Knoten wie ein Hamster, der endlos am Rad läuft, keine neuen Transaktionen verarbeiten können. Deshalb nennen wir diesen einzigartigen Angriffstyp einen „Hamsterrad“-Angriff.
Nachdem CertiK die Schwachstelle entdeckt hatte, meldete sie Sui über das Bug-Bounty-Programm von Sui. Auch Sui reagierte so schnell wie möglich effektiv, bestätigte die Schwere der Schwachstelle und ergriff aktiv entsprechende Maßnahmen, um das Problem vor dem Start des Mainnets zu beheben. Zusätzlich zur Behebung dieser spezifischen Sicherheitslücke hat Sui vorbeugende Maßnahmen zur Schadensbegrenzung implementiert, um den potenziellen Schaden zu reduzieren, der durch diese Sicherheitslücke verursacht werden könnte.
Um dem CertiK-Team für die verantwortungsvolle Offenlegung zu danken, gewährte Sui dem CertiK-Team einen Bonus von 500.000 US-Dollar.
Die folgenden technischen Details dieser kritischen Sicherheitslücke werden offengelegt, um die Grundursache und mögliche Auswirkungen der Sicherheitslücke zu klären.
Detaillierte Erläuterung der Schwachstellen
Die Schlüsselrolle von Validatoren in Sui
Bei Blockchains, die auf der Move-Sprache basieren, wie Sui und Aptos, ist der Garantiemechanismus zur Verhinderung böswilliger Payload-Angriffe hauptsächlich statische Verifizierungstechnologie. Durch statische Verifizierungstechnologie kann Sui die Gültigkeit der von Benutzern übermittelten Nutzdaten überprüfen, bevor der Vertrag freigegeben oder aktualisiert wird. Der Validator stellt eine Reihe von Prüfern bereit, um die Richtigkeit der Struktur und Semantik sicherzustellen. Erst nach bestandener Prüfung und Verifizierung gelangt der Vertrag zur Ausführung in die virtuelle Maschine.
Bösartige Payload-Bedrohungen in der Move-Kette
Die Sui-Kette bietet einen neuen Satz von Speichermodellen und Schnittstellen zusätzlich zur ursprünglichen virtuellen Move-Maschine, sodass Sui über eine angepasste Version der virtuellen Move-Maschine verfügt. Um die neuen Speicherprimitive zu unterstützen, führt Sui außerdem eine Reihe zusätzlicher, benutzerdefinierter Prüfungen zur Sicherheitsüberprüfung nicht vertrauenswürdiger Nutzlasten ein, beispielsweise Objektsicherheit und globaler Speicherzugriff. Diese benutzerdefinierten Schecks passen zu den einzigartigen Funktionen von Sui, daher nennen wir diese benutzerdefinierten Schecks Sui-Validatoren.
Suis Befehl, die Ladung zu überprüfen
Wie in der Abbildung oben dargestellt, führen die meisten Prüfungen im Validator eine Sicherheitsüberprüfung auf struktureller Ebene anhand des CompiledModule durch (das den vom Benutzer bereitgestellten Vertragsnutzlastlauf darstellt). Verwenden Sie beispielsweise den „Duplicate Checker“, um sicherzustellen, dass es keine doppelten Einträge in der Laufzeitnutzlast gibt. Verwenden Sie den „Limit Checker“, um sicherzustellen, dass die Länge jedes Felds in der Laufzeitnutzlast innerhalb der zulässigen Eintragsbegrenzung liegt.
Zusätzlich zu Prüfungen auf struktureller Ebene erfordert die statische Prüfung des Verifizierers noch komplexere Analysemethoden, um die Robustheit der nicht vertrauenswürdigen Nutzlast auf semantischer Ebene sicherzustellen.
Erfahren Sie mehr über den abstrakten Interpreter von Move:
Lineare und iterative Analyse
Der von Move bereitgestellte abstrakte Interpreter ist ein Framework, das speziell für die Durchführung komplexer Sicherheitsanalysen von Bytecode durch abstrakte Interpretation entwickelt wurde. Durch diesen Mechanismus wird der Verifizierungsprozess verfeinert und genauer, und jeder Verifizierer kann seinen eindeutigen abstrakten Zustand für die Analyse definieren.
Beim Starten eines Laufs erstellt der abstrakte Interpreter aus den kompilierten Modulen ein Kontrollflussdiagramm (CFG). Jeder Basisblock in diesen CFG behält eine Reihe von Zuständen bei, nämlich „Vorbestellungsstatus“ und „Nachbestellungsstatus“. Der „Pre-Order-Status“ liefert eine Momentaufnahme des Programmstatus vor der Ausführung des Basisblocks, während der „Post-Order-Status“ eine Beschreibung des Programmstatus nach der Ausführung des Basisblocks liefert.
Wenn der abstrakte Interpreter im Kontrollflussdiagramm keine Sprünge (oder Schleifen) findet, folgt er einem einfachen linearen Ausführungsprinzip: Jeder Basisblock wird der Reihe nach analysiert und die vorherige Anweisung wird basierend auf der Semantik jeder Anweisung im Block berechnet. sequentieller Zustand und postsequentieller Zustand. Das Ergebnis ist eine genaue Momentaufnahme jedes grundlegenden Blockebenenstatus eines Programms während der Ausführung, die dabei hilft, die Sicherheitseigenschaften des Programms zu überprüfen.
Abstrakter Interpreter-Workflow verschieben
Allerdings wird dieser Prozess komplizierter, wenn es Schleifen im Kontrollfluss gibt. Das Auftreten einer Schleife bedeutet, dass das Kontrollflussdiagramm eine Sprungkante enthält. Die Quelle der Sprungkante entspricht dem nachfolgenden Zustand des aktuellen Basisblocks und der Zielbasisblock (Schleifenkopf) der Sprungkante ist ein zuvor analysierter Zustand Der Vorbestellungsstatus des Basisblocks, daher muss der abstrakte Interpreter die Zustände der beiden Basisblöcke im Zusammenhang mit dem Sprung sorgfältig zusammenführen.
Wenn sich herausstellt, dass sich der zusammengeführte Zustand vom bestehenden Vorbestellungszustand des Schleifenkopf-Basisblocks unterscheidet, aktualisiert der abstrakte Interpreter den Zustand des Schleifenkopf-Basisblocks und startet die Analyse ausgehend von diesem Basisblock neu. Dieser iterative Analyseprozess wird fortgesetzt, bis der Schleifenvorzustand stabil ist. Mit anderen Worten: Dieser Vorgang wird wiederholt, bis sich der Vorbestellungszustand des Basisblocks am Anfang der Schleife zwischen den Iterationen nicht mehr ändert. Das Erreichen eines Fixpunkts zeigt an, dass die Schleifenanalyse abgeschlossen ist.
Dieser IDLeak-Validator:
Maßgeschneiderte abstrakte Interpretationsanalyse
Im Gegensatz zum ursprünglichen Move-Design führt die Blockchain-Plattform von Sui ein einzigartiges, „zielorientiertes“ globales Speichermodell ein. Ein bemerkenswertes Merkmal dieses Modells besteht darin, dass jede Datenstruktur mit einem Schlüsselattribut (das als Index in der Kette gespeichert wird) den ID-Typ als erstes Feld der Struktur haben muss. Das ID-Feld ist unveränderlich und kann nicht auf andere Ziele übertragen werden, da jedes Objekt eine weltweit eindeutige ID haben muss. Um diese Eigenschaften sicherzustellen, hat Sui eine Reihe benutzerdefinierter Analyselogik auf dem abstrakten Interpreter aufgebaut.
Der IDLeak-Verifizierer, auch bekannt als id_leak_verifier, arbeitet mit dem abstrakten Interpreter zusammen, um Analysen durchzuführen. Es verfügt über eine eigene einzigartige AbstractDomain namens AbstractState. Jeder AbstractState besteht aus AbstractValue, der mehreren lokalen Variablen entspricht. Überwachen Sie den Status jeder lokalen Variablen über AbstractValue, um zu verfolgen, ob eine ID-Variable neu ist.
Während des Strukturverpackungsprozesses erlaubt der IDLeak-Validator nur das Packen einer neuen ID in eine Struktur. Durch abstrakte Interpretationsanalyse kann der IDLeak-Validator den lokalen Datenflussstatus umfassend verfolgen, um sicherzustellen, dass keine vorhandenen IDs an andere Strukturobjekte übertragen werden.
Sui Inkonsistenzproblem bei der Wartung des IDLeak-Validatorstatus
Der IDLeak-Validator wird durch Implementierung der AbstractState::join-Funktion in den Move-Abstract-Interpreter integriert. Diese Funktion spielt eine wesentliche Rolle in der Zustandsverwaltung, insbesondere bei der Zusammenführung und Aktualisierung von Zustandswerten.
Untersuchen Sie diese Funktionen im Detail, um ihre Funktionsweise zu verstehen:
In AbstractState::join nimmt die Funktion einen anderen AbstractState als Eingabe und versucht, seinen lokalen Zustand mit dem lokalen Zustand des aktuellen Objekts zusammenzuführen. Für jede lokale Variable im Eingabestatus wird der Wert der Variablen mit ihrem aktuellen Wert im lokalen Status verglichen (falls nicht gefunden, ist der Standardwert AbstractValue::Other). Wenn die beiden Werte nicht gleich sind, wird ein „geändert“-Flag als Grundlage dafür gesetzt, ob sich das endgültige Ergebnis der Zustandszusammenführung geändert hat, und der lokale Variablenwert im lokalen Zustand wird durch Aufrufen von AbstractValue::join aktualisiert.
In AbstractValue::join vergleicht die Funktion ihren Wert mit einem anderen AbstractValue. Wenn sie gleich sind, wird der übergebene Wert zurückgegeben. Wenn nicht gleich, wird AbstractValue::Other zurückgegeben.
Allerdings birgt diese Zustandserhaltungslogik ein verstecktes Inkonsistenzproblem. Obwohl AbstractState::join ein Ergebnis zurückgibt, das angibt, dass sich der zusammengeführte Status geändert hat (JoinResult::Changed), basierend auf der Differenz zwischen dem alten und dem neuen Wert, kann der zusammengeführte aktualisierte Statuswert immer noch unverändert bleiben.
Dieses Inkonsistenzproblem wird durch die Reihenfolge der Operationen verursacht: Die Bestimmung des geänderten Status in AbstractState::join erfolgt vor der Statusaktualisierung (AbstractValue::join), und diese Bestimmung spiegelt nicht das tatsächliche Ergebnis der Statusaktualisierung wider.
Darüber hinaus spielt AbstractValue::Other in AbstractValue::join eine entscheidende Rolle für das Ergebnis der Fusion. Wenn beispielsweise der alte Wert AbstractValue::Other und der neue Wert AbstractValue::Fresh ist, ist der aktualisierte Statuswert immer noch AbstractValue::Other. Auch wenn der alte und der neue Wert unterschiedlich sind, ist dies beim Status selbst nicht der Fall Änderung nach dem Update.
Beispiel: Inkohärenz in Staatszusammenhängen
Dies führt zu einer Inkonsistenz: Das Ergebnis der Zusammenführung der grundlegenden Blockzustände wird als „geändert“ beurteilt, der Wert des zusammengeführten Zustands selbst hat sich jedoch nicht geändert. Im Prozess der abstrakten Interpretation und Analyse kann das Auftreten solcher Inkonsistenzen schwerwiegende Folgen haben. Wir überprüfen das Verhalten des abstrakten Interpreters, wenn Schleifen in einem Kontrollflussdiagramm (CFG) auftreten:
Wenn eine Schleife auftritt, verwendet der abstrakte Interpreter eine iterative Analysemethode, um den Status des Sprungziel-Basisblocks mit dem aktuellen Basisblock zusammenzuführen. Wenn sich der zusammengeführte Zustand ändert, führt der abstrakte Interpreter eine erneute Analyse ausgehend vom Sprungziel durch.
Wenn jedoch die Zusammenführungsoperation der abstrakten Interpretationsanalyse das Ergebnis der Zustandszusammenführung fälschlicherweise als „geändert“ markiert, obwohl sich der Wert der internen Variablen des Zustands tatsächlich nicht geändert hat, führt dies zu einer endlosen Neuanalyse und erzeugt eine Endlosschleife .
die Inkonsistenz weiter ausnutzen
Lösen Sie eine Endlosschleife im Sui IDLeak-Validator aus
Unter Ausnutzung dieser Inkonsistenz kann ein Angreifer ein böswilliges Kontrollflussdiagramm erstellen, um den IDLeak-Validator in eine Endlosschleife zu versetzen. Dieses sorgfältig erstellte Kontrollflussdiagramm besteht aus drei Grundblöcken: BB1 und BB2, BB3. Es ist erwähnenswert, dass wir absichtlich eine Sprungkante von BB3 nach BB2 eingeführt haben, um eine Schleife zu erstellen.
Ein bösartiger CFG+-Status kann zu einer Endlosschleife innerhalb des IDLeak-Validators führen.
Der Prozess beginnt mit BB2, wo der AbstractValue einer bestimmten lokalen Variablen auf ::Other gesetzt wird. Nach der Ausführung von BB2 wird der Prozess zu BB3 übertragen, wo dieselbe Variable auf ::Fresh gesetzt wird. Am Ende von BB3 gibt es eine Sprungkante, die zu BB2 springt.
Bei der abstrakten Interpretation und Analyse dieses Beispiels spielt die zuvor erwähnte Inkonsistenz eine Schlüsselrolle. Wenn die Sprungkante verarbeitet wird, versucht der abstrakte Interpreter, den Post-Order-Status von BB3 (die Variable ist „::Fresh“) mit dem Vor-Order-Status von BB2 (die Variable ist „::Other“) zu verbinden. Die Funktion AbstractState::join hat den Unterschied zwischen dem alten und dem neuen Wert festgestellt und das Flag „Änderung“ gesetzt, um anzuzeigen, dass BB2 erneut analysiert werden muss.
Das dominante Verhalten von „::Other“ in AbstractValue::join bedeutet jedoch, dass nach der Zusammenführung von AbstractValue der tatsächliche Wert der BB2-Statusvariablen immer noch „::Other“ ist und sich das Ergebnis der Statuszusammenführung nicht geändert hat.
Sobald dieser zyklische Prozess beginnt, d. h. während der Validator BB2 und alle seine nachfolgenden Basisblockknoten (in diesem Fall BB3) erneut analysiert, wird er auf unbestimmte Zeit fortgesetzt. Die Endlosschleife verbraucht alle verfügbaren CPU-Zyklen, sodass keine Antworten auf neue Transaktionen verarbeitet werden können. Diese Situation bleibt bestehen, nachdem der Validator neu gestartet wurde.
Durch die Ausnutzung dieser Schwachstelle laufen Validierungsknoten in einer Endlosschleife wie ein Hamster, der endlos auf einem Rad läuft, und sind nicht in der Lage, neue Transaktionen zu verarbeiten. Deshalb nennen wir diesen einzigartigen Angriffstyp einen „Hamsterrad“-Angriff.
Ein „Hamsterrad“-Angriff kann den Sui-Validator effektiv zum Stillstand bringen und dadurch das gesamte Sui-Netzwerk lahmlegen.
Nachdem wir die Ursache und den Auslöseprozess der Sicherheitslücke verstanden hatten, erstellten wir mithilfe der folgenden Move-Bytecode-Simulation ein konkretes Beispiel und lösten die Sicherheitslücke in der Simulation in der realen Umgebung erfolgreich aus:
Dieses Beispiel zeigt, wie die Schwachstelle in einer realen Umgebung durch sorgfältig konstruierten Bytecode ausgelöst wird. Konkret kann ein Angreifer eine Endlosschleife im IDLeak-Validator auslösen, indem er eine Nutzlast von knapp 100 Bytes verwendet, um alle CPU-Zyklen eines Sui-Knotens zu verbrauchen, wodurch effektiv die Verarbeitung neuer Transaktionen verhindert und ein Denial-of-Service im Sui-Netzwerk verursacht wird .
Der anhaltende Schaden durch „Hamsterrad“-Angriffe im Sui-Netzwerk
Das Bug-Bounty-Programm von Sui unterliegt strengen Vorschriften zur Bewertung des Verwundbarkeitsgrads, die hauptsächlich auf dem Grad der Schädigung des gesamten Netzwerks basieren. Eine Schwachstelle, die die Einstufung „kritisch“ erfüllt, muss das gesamte Netzwerk lahmlegen und die Bestätigung neuer Transaktionen effektiv verhindern. Wenn die Schwachstelle nur dazu führen kann, dass einige Netzwerkknoten den Dienst verweigern, ist ein Hard Fork erforderlich, um das Problem zu beheben Schwachstellen werden höchstens als „mittleres Risiko“ (mittel) oder „hohes Risiko“ (hoch) eingestuft.
Die vom CertiK Skyfall-Team entdeckte „Hamsterrad“-Schwachstelle kann das gesamte Sui-Netzwerk lahmlegen und erfordert die offizielle Veröffentlichung einer neuen Version, um sie zu aktualisieren und zu beheben. Basierend auf der Schwere der Sicherheitslücke stufte Sui diese letztendlich als „kritisch“ ein. Um die schwerwiegenden Auswirkungen des „Hamsterrad“-Angriffs besser zu verstehen, müssen wir die komplexe Architektur des Backend-Systems von Sui verstehen, insbesondere den gesamten Prozess der Freigabe oder Aktualisierung von On-Chain-Transaktionen.
Interaktionsübersicht für die Übermittlung von Transaktionen in Sui
Zunächst werden Benutzertransaktionen über Front-End-RPC übermittelt und nach der grundlegenden Überprüfung an den Back-End-Dienst weitergeleitet. Der Sui-Backend-Dienst ist für die weitere Validierung der eingehenden Transaktionsnutzlast verantwortlich. Nach erfolgreicher Überprüfung der Signatur des Benutzers wird die Transaktion in ein Transaktionszertifikat umgewandelt (das die Transaktionsinformationen sowie die Signatur von Sui enthält).
Diese Transaktionszertifikate sind ein wesentlicher Bestandteil des Betriebs des Sui-Netzwerks und können zwischen verschiedenen Verifizierungsknoten im Netzwerk weitergegeben werden. Bei Transaktionen zur Vertragserstellung/-aktualisierung ruft der Verifizierungsknoten den Sui-Validator auf, um die Gültigkeit der Vertragsstruktur/-semantik dieser Zertifikate zu prüfen und zu verifizieren, bevor sie in die Kette aufgenommen werden können. Während dieser kritischen Überprüfungsphase kann die Schwachstelle „Endlosschleife“ ausgelöst und ausgenutzt werden.
Wenn die Sicherheitslücke ausgelöst wird, wird der Verifizierungsprozess auf unbestimmte Zeit unterbrochen, was die Fähigkeit des Systems zur Verarbeitung neuer Transaktionen beeinträchtigt und zu einer vollständigen Abschaltung des Netzwerks führt. Erschwerend kommt hinzu, dass die Situation nach dem Neustart des Knotens immer noch besteht, was bedeutet, dass herkömmliche Abhilfemaßnahmen bei weitem nicht ausreichen. Sobald diese Schwachstelle ausgelöst wird, kommt es zu „kontinuierlichen Schäden“, die nachhaltige Auswirkungen auf das gesamte Sui-Netzwerk haben.
Suis Lösung
Nach Rückmeldung von CertiK bestätigte Sui umgehend die Schwachstelle und veröffentlichte einen Fix, um den kritischen Fehler zu beheben. Der Fix stellt die Konsistenz zwischen Statusänderungen und Post-Change-Flags sicher und eliminiert die kritischen Auswirkungen von „Hamsterrad“-Angriffen.
Um die oben genannte Inkonsistenz zu beseitigen, enthält Suis Fix eine kleine, aber wichtige Anpassung der Funktion AbstractState::join. Dieser Patch entfernt die Logik zur Bestimmung des Zustandszusammenführungsergebnisses vor der Ausführung von AbstractValue::join. Stattdessen führt er zunächst die Funktion AbstractValue::join aus, um die Zustandszusammenführung durchzuführen, und legt fest, ob die Zusammenführung erfolgt, indem das endgültige Aktualisierungsergebnis mit dem ursprünglichen Zustand verglichen wird Wert (old_value).
Auf diese Weise stimmt das Ergebnis der Zustandszusammenführung mit dem Ergebnis einer tatsächlichen Aktualisierung überein und es tritt während des Analyseprozesses keine Endlosschleife auf.
Zusätzlich zur Behebung dieser spezifischen Schwachstelle hat Sui Abhilfemaßnahmen implementiert, um die Auswirkungen zukünftiger Validator-Schwachstellen zu reduzieren. Laut Suis Antwort im Fehlerbericht umfasst die Abhilfe eine Funktion namens Denylist.
„Validatoren verfügen jedoch über eine Knotenkonfigurationsdatei, die es ihnen ermöglicht, bestimmte Kategorien von Transaktionen vorübergehend abzulehnen. Diese Konfiguration kann verwendet werden, um die Verarbeitung von Releases und Paket-Upgrades vorübergehend zu deaktivieren. Aufgrund dieses Fehlers ist es notwendig, Sui auszuführen, bevor ein Release oder ein Paket signiert wird.“ Aktualisieren Sie TX, während eine Verweigerungsliste die Ausführung des Validators stoppt und den schädlichen TX verwirft. Das vorübergehende Verweigern der Auflistung dieser TX-Typen stellt eine zu 100 % wirksame Abhilfe dar (obwohl dadurch der Dienst für jeden, der versucht, den Code freizugeben oder zu aktualisieren, vorübergehend unterbrochen wird).
Übrigens haben wir diese TX-Deny-List-Konfigurationsdatei schon seit einiger Zeit, aber wir haben auch einen ähnlichen Mechanismus für Zertifikate hinzugefügt, um die Schwachstelle „Validator-Endlosschleife“, die Sie zuvor gemeldet haben, zu beheben. Mit diesem Mechanismus haben wir mehr Flexibilität bei diesem Angriff: Wir werden die Konfiguration der Zertifikatsverweigerungsliste verwenden, um den Validator fehlerhafte Zertifikate vergessen zu lassen (die Endlosschleife zu durchbrechen), und die Konfiguration der TX-Verweigerungsliste, um Releases/Upgrades zu deaktivieren. Dadurch wird die Entstehung neuer böswilliger Angriffstransaktionen verhindert. Vielen Dank, dass Sie uns zum Nachdenken gebracht haben!
Ein Validator verfügt (im Gegensatz zu Gas) über eine begrenzte Anzahl von „Ticks“ für die Bytecode-Überprüfung vor dem Signieren einer Transaktion. Wenn der gesamte in einer Transaktion ausgegebene Bytecode nicht in so vielen Ticks überprüft werden kann, verweigert der Validator das Signieren der Transaktion und verhindert so dies im Netzwerk ausführen. Bisher funktionierte die Messung nur für einen ausgewählten Satz komplexer Prüfdurchläufe. Um dieses Problem zu lösen, erweitern wir die Messung auf jeden Validator, um sicherzustellen, dass die Arbeit des Validators während des Verifizierungsprozesses jedes Ticks eingeschränkt wird. Wir haben außerdem einen potenziellen Endlosschleifenfehler im ID-Leak-Validator behoben. "
--Anweisungen von Sui-Entwicklern zu Fehlerbehebungen
Alles in allem ermöglicht Denylist Validatoren, Exploits in Validatoren vorübergehend zu umgehen und potenziellen Schaden durch einige böswillige Transaktionen effektiv zu verhindern, indem der Release- oder Upgrade-Prozess deaktiviert wird. Wenn die Abhilfemaßnahmen von Denylist wirksam werden, stellen Knoten sicher, dass sie weiterarbeiten können, indem sie ihre eigenen Veröffentlichungs-/Aktualisierungsvertragsfunktionen opfern.
Zusammenfassen
In diesem Artikel teilen wir die technischen Details des vom CertiK Skyfall-Team entdeckten „Hamsterrad“-Angriffs und erklären, wie dieser neue Angriff wichtige Schwachstellen ausnutzt, um das Sui-Netzwerk vollständig abzuschalten. Darüber hinaus haben wir uns die rechtzeitige Reaktion von Sui zur Behebung dieses kritischen Problems genauer angesehen und die Behebung der Schwachstelle sowie nachfolgende Abhilfemethoden für ähnliche Schwachstellen vorgestellt.