Read-Only-Reentrancy: Die unterschätzte Variante

Definition

Read-Only-Reentrancy ist eine spezifische Art von Smart-Contract-Schwachstelle, die einen temporären, inkonsistenten Zustand innerhalb eines Vertrags ausnutzt. Im Gegensatz zur traditionellen Reentrancy, die sich auf die wiederholte Ausführung zustandsändernder Funktionen konzentriert, nutzt Read-Only-Reentrancy die Möglichkeit, eine "View"- oder "Pure"-Funktion von einem externen Vertrag während einer Zwischenphase einer Transaktion aufzurufen. Dies geschieht, bevor die ursprüngliche Operation vollständig abgeschlossen und alle relevanten Zustandsvariablen aktualisiert wurden. Dadurch kann ein Angreifer einen veralteten oder manipulierten Wert auslesen, der dann zur Beeinflussung nachfolgender Operationen oder der Logik eines abhängigen Vertrags verwendet werden kann. Die Gefahr liegt darin, dass diese "Lese"-Operationen, die typischerweise als harmlos gelten, zu Angriffsvektoren werden können, wenn die zugrunde liegenden Daten, auf die sie zugreifen, vorübergehend nicht mit dem wahren Zustand des Vertrags synchron sind.

Read-Only-Reentrancy ist eine Smart-Contract-Schwachstelle, bei der ein Angreifer eine View-Funktion während eines inkonsistenten Zwischenzustands einer Transaktion aufruft, um manipulierte oder veraltete Daten zu erhalten und die nachfolgende Vertragslogik zu beeinflussen.

Diese Schwachstelle tritt häufig auf, wenn ein Vertrag einen externen Aufruf an einen anderen Vertrag initiiert und dieser externe Vertrag (potenziell vom Angreifer kontrolliert) dann den ursprünglichen Vertrag erneut aufruft, um eine View-Funktion abzufragen. Wenn die Zustandsvariablen des ursprünglichen Vertrags, von denen die View-Funktion abhängt, zum Zeitpunkt dieses erneuten Aufrufs noch nicht vollständig aktualisiert wurden, um die laufende Transaktion widerzuspiegeln, gibt die View-Funktion einen falschen Wert zurück. Dieser falsche Wert kann dann vom Angreifervertrag verwendet werden, um Entscheidungen zu treffen, die für den Opfervertrag oder seine Benutzer nachteilig sind. Dies verdeutlicht einen kritischen Aspekt des Smart-Contract-Designs: Die Reihenfolge der Operationen, insbesondere Zustandsaktualisierungen im Verhältnis zu externen Aufrufen, ist für die Sicherheit von größter Bedeutung.

Kernaussage

Die Kernaussage der Read-Only-Reentrancy liegt in ihrer Fähigkeit, Entscheidungsprozesse in Smart Contracts durch die Bereitstellung falscher oder veralteter Informationen zu manipulieren, selbst ohne den Zustand des Vertrags während des reentranten Aufrufs direkt zu ändern. Diese Schwachstelle unterstreicht, dass selbst scheinbar harmlose "Lese"-Operationen zu einer Waffe werden können, wenn sie nicht ordnungsgemäß gegen inkonsistente Zwischenzustände abgesichert sind. Entwickler konzentrieren sich oft darauf, sich mit dem Checks-Effects-Interactions-Muster vor zustandsändernder Reentrancy zu schützen, aber Read-Only-Reentrancy zeigt, dass das Timing externer Aufrufe und nachfolgender Datenlesevorgänge ebenso kritisch ist.

Diese subtile Angriffsform kann zu erheblichen finanziellen Verlusten führen, indem sie Verträge dazu veranlasst, Preise, Sicherheitenwerte oder andere kritische Metriken falsch zu berechnen. Sie erzwingt eine Neubewertung von Sicherheitsannahmen, insbesondere hinsichtlich der Unveränderlichkeit von Daten während komplexer, mehrstufiger Transaktionen, die externe Aufrufe beinhalten. Die Kernaussage ist, dass jeder externe Aufruf, unabhängig von seinem offensichtlichen Zweck, einen potenziellen Reentrancy-Vektor darstellt, und Entwickler nicht nur Zustandsänderungen, sondern auch die Integrität der von View-Funktionen während solcher Aufrufe gelesenen Daten berücksichtigen müssen.

Mechanik

Die Mechanik eines Read-Only-Reentrancy-Angriffs beinhaltet typischerweise eine spezifische Abfolge von Ereignissen. Zuerst initiiert ein Opfer-Smart-Contract einen externen Aufruf an einen anderen Vertrag. Dieser externe Aufruf könnte eine Token-Übertragung (z.B. das Senden von ETH oder einem ERC-20-Token), ein Aufruf an ein anderes DeFi-Protokoll oder jede Interaktion sein, die die Code-Ausführung im Empfängervertrag auslöst. Wenn der Empfängervertrag ein vom Angreifer kontrollierter Vertrag ist, wird dessen Fallback- oder Receive-Funktion ausgelöst.

Innerhalb dieser ausgelösten Fallback-Funktion führt der Angreifervertrag dann einen erneuten Aufruf zurück zum ursprünglichen Opfervertrag durch. Entscheidend ist, dass dieser erneute Aufruf eine View-Funktion (oder eine Pure-Funktion) des Opfervertrags zum Ziel hat. Die Schwachstelle entsteht, wenn zum Zeitpunkt dieses erneuten Aufrufs die internen Zustandsvariablen des Opfervertrags, auf die die View-Funktion angewiesen ist, noch nicht vollständig aktualisiert wurden, um den ursprünglichen externen Aufruf widerzuspiegeln. Wenn beispielsweise eine Auszahlungsfunktion zuerst Gelder sendet und dann das Guthaben des Benutzers aktualisiert, könnte ein Angreifer nach dem Empfang der Gelder, aber bevor das Guthaben reduziert wird, erneut eintreten. Die View-Funktion würde, wenn sie in diesem Zeitfenster aufgerufen wird, einen Wert basierend auf dem veralteten Guthaben zurückgeben und effektiv mehr Gelder anzeigen, als tatsächlich verfügbar sind, oder einen anderen als den beabsichtigten Preis.

Betrachten wir ein Szenario, in dem ein Tresorvertrag den Anteil eines Benutzers an den gesamten Token basierend auf totalTokens und userBalance berechnet. Eine Auszahlungsfunktion könnte zuerst Token an den Benutzer senden und dann userBalance und totalTokens aktualisieren. Wenn der Vertrag des Benutzers bösartig ist, könnte seine Fallback-Funktion beim Empfang der Token ausgelöst werden. Innerhalb dieser Fallback-Funktion könnte der bösartige Vertrag eine View-Funktion im Tresor aufrufen, die den "aktuellen Preis" oder "Anteilswert" basierend auf totalTokens berechnet. Wenn totalTokens noch nicht aktualisiert wurde, um die ausgehende Auszahlung widerzuspiegeln, würde die View-Funktion einen überhöhten Wert zurückgeben. Dieser überhöhte Wert könnte dann vom Angreifervertrag verwendet werden, um nachfolgende Aktionen zu manipulieren, wie z.B. das Leihen gegen einen künstlich hohen Sicherheitenwert oder die Ausnutzung eines Preisorakels. Das kritische Element ist die temporäre Inkonsistenz von Zustandsvariablen, auf die View-Funktionen angewiesen sind und die während des Ausführungsflusses eines externen Aufrufs exponiert werden.

Trading-Relevanz

Read-Only-Reentrancy ist zwar keine direkte Handelsstrategie, hat aber tiefgreifende Auswirkungen auf die Sicherheit und Integrität von dezentralen Finanzprotokollen (DeFi), die das Rückgrat des On-Chain-Tradings bilden. Ihre Relevanz für das Trading ergibt sich aus ihrem Potenzial, kritische Datenpunkte zu manipulieren, die direkt die Vermögenspreise, Sicherheitenbewertungen und Arbitragemöglichkeiten beeinflussen. Viele DeFi-Protokolle, wie z.B. Kreditplattformen, dezentrale Börsen (DEXs) und Plattformen für synthetische Vermögenswerte, verlassen sich stark auf externe Aufrufe an Preisorakel oder andere Verträge, um Vermögenswerte, Zinssätze oder Liquidationsschwellen zu bestimmen.

Wenn ein Preisorakel-Vertrag anfällig für Read-Only-Reentrancy ist, könnte ein Angreifer ihn ausnutzen, um vorübergehend einen falschen Vermögenspreis zu melden. Dieser manipulierte Preis könnte dann verwendet werden, um profitable Trades auszuführen, wie z.B. das Leihen von mehr Vermögenswerten, als durch Sicherheiten gerechtfertigt ist, das ungerechte Liquidieren von Positionen oder das Ausnutzen von Arbitragemöglichkeiten auf DEXs, die sich auf das kompromittierte Orakel verlassen. Stellen Sie sich ein Szenario vor, in dem ein Liquiditätspool einer DEX den Preis eines Tokens basierend auf seinen aktuellen Reserven berechnet. Wenn eine große Auszahlung initiiert wird und ein Angreifer erneut eintreten kann, um den Preis abzufragen, bevor die Reserven vollständig aktualisiert werden, könnte er einen künstlich niedrigen oder hohen Preis erhalten, was ihm ermöglicht, zu einem manipulierten Kurs zu kaufen oder zu verkaufen. Dies beeinträchtigt direkt die Fairness und Effizienz des Tradings und führt zu erheblichen finanziellen Verlusten für legitime Trader und Liquiditätsanbieter.

Darüber hinaus ist die Integrität der Sicherheitenberechnungen in Kreditprotokollen für das Trading von größter Bedeutung. Wenn ein Angreifer den gemeldeten Wert seiner Sicherheiten durch einen Read-Only-Reentrancy-Angriff auf einen abhängigen Vertrag manipulieren kann, könnte er übermäßige Beträge leihen, was zu unterbesicherten Krediten und potenziellen uneinbringlichen Forderungen für das Protokoll führt. Dies beeinträchtigt nicht nur die Stabilität des Kreditmarktes, sondern schafft auch systemische Risiken für andere Protokolle, die damit integriert sind. Das Verständnis und die Minderung von Read-Only-Reentrancy ist daher für jeden, der am On-Chain-Trading beteiligt ist, unerlässlich, da es die Zuverlässigkeit der Daten und Mechanismen, die die Vermögensbewertung und den Austausch regeln, direkt beeinflusst.

Risiken

Die mit Read-Only-Reentrancy verbundenen Risiken sind erheblich und vielschichtig und reichen über unmittelbare finanzielle Verluste hinaus bis hin zu umfassenderen systemischen Bedenken innerhalb des Blockchain-Ökosystems. Das unmittelbarste Risiko ist der finanzielle Verlust für Benutzer und das Protokoll selbst. Angreifer können manipulierte Daten ausnutzen, um Gelder abzuziehen, Vermögenswerte zu unfairen Preisen zu erwerben oder gegen nicht existierende Sicherheiten zu leihen, was zu direkten monetären Schäden führt. Wenn beispielsweise die Sicherheitenbewertung eines Kreditprotokolls kompromittiert wird, könnten Benutzer ihre eingezahlten Gelder verlieren, und das Protokoll könnte erhebliche uneinbringliche Forderungen erleiden.

Über die direkten finanziellen Auswirkungen hinaus birgt Read-Only-Reentrancy erhebliche Reputationsschäden für betroffene Projekte und den breiteren DeFi-Bereich. Ein erfolgreicher Exploit untergräbt das Vertrauen der Benutzer, was es für Projekte schwieriger macht, Liquidität und Benutzer anzuziehen. Dieser Vertrauensverlust kann langfristige Folgen haben und Innovation und Akzeptanz behindern. Darüber hinaus macht die Subtilität dieser Schwachstelle sie bei Sicherheitsaudits besonders gefährlich. Traditionelle Reentrancy-Prüfungen konzentrieren sich oft auf zustandsändernde Funktionen und Reentrancy-Guards, wobei die Risiken, die mit View-Funktionen verbunden sind, die inkonsistente Zustände lesen, möglicherweise übersehen werden. Dies erschwert die Erkennung und erhöht die Wahrscheinlichkeit, dass solche Schwachstellen in den Produktionscode gelangen.

Ein weiteres erhebliches Risiko ist das Potenzial für systemische Risiken über miteinander verbundene DeFi-Protokolle hinweg. Viele Protokolle verlassen sich auf externe Verträge für kritische Daten, wie z.B. Preis-Feeds, Governance-Entscheidungen oder Liquiditätsbereitstellung. Wenn ein grundlegender Vertrag anfällig für Read-Only-Reentrancy ist, kann dies einen Kaskadeneffekt erzeugen und die Integrität aller abhängigen Protokolle kompromittieren. Diese Vernetzung bedeutet, dass eine einzige, subtile Schwachstelle weitreichende Folgen haben kann, die die Stabilität des gesamten Ökosystems beeinträchtigen. Letztendlich untergrägt das Vorhandensein solcher Schwachstellen das Kernversprechen des dezentralen Finanzwesens: sichere, transparente und vertrauenslose Operationen.

Geschichte und Beispiele

Während traditionelle Reentrancy-Angriffe, die durch den DAO-Hack im Jahr 2016 berühmt wurden, gut dokumentiert sind, ist Read-Only-Reentrancy eine neuer erkannte und oft unterschätzte Variante. Ihre subtile Natur bedeutet, dass spezifische, namentlich genannte Exploits seltener auf die gleiche dramatische Weise veröffentlicht werden wie direkte Geldabzüge. Sicherheitsforschungsteams und Auditoren haben diese Schwachstellenklasse jedoch zunehmend hervorgehoben, wobei Berichte darauf hindeuten, dass sie für die Gefährdung von "über 100 Millionen US-Dollar an Geldern" in verschiedenen Protokollen verantwortlich war. Dies deutet darauf hin, dass die kumulativen Auswirkungen solcher Schwachstellen erheblich waren, auch wenn sie nicht immer zu einem einzigen, massiven, namentlich genannten Hack führten.

Ein häufiges hypothetisches, aber sehr realistisches Beispiel betrifft ein Kreditprotokoll, das mit einem benutzerdefinierten Preisorakel interagiert. Stellen Sie sich einen Kreditvertrag vor, der es Benutzern ermöglicht, Sicherheiten einzuzahlen und Stablecoins zu leihen. Der Betrag, den ein Benutzer leihen kann, wird durch den Aufruf einer getCurrentPrice()-View-Funktion in einem externen Preisorakel-Vertrag bestimmt. Betrachten wir nun die interne Logik des Orakels: Es könnte seine Variable totalValueLocked nachdem ein externer withdraw-Aufruf an einen Benutzer getätigt wurde, aber bevor die Transaktion vollständig abgeschlossen ist, aktualisieren. Ein Angreifer könnte einen bösartigen Vertrag erstellen, der beim Empfang von Geldern aus der withdraw-Funktion des Orakels sofort das Orakel erneut aufruft, um getCurrentPrice() aufzurufen. In diesem kurzen Zeitfenster könnte totalValueLocked immer noch den Zustand vor der Auszahlung widerspiegeln, was dazu führt, dass getCurrentPrice() einen künstlich überhöhten Preis zurückgibt. Der Angreifer könnte diesen überhöhten Preis dann nutzen, um mehr Stablecoins vom Kreditprotokoll zu leihen, als seine tatsächlichen Sicherheiten rechtfertigen, was zu einem unterbesicherten Kredit führt.

Ein weiteres Szenario könnte einen Liquiditätspool einer dezentralen Börse (DEX) betreffen. Wenn ein großer Swap oder eine Auszahlung erfolgt, werden die internen Reserven des Pools aktualisiert. Wenn ein Angreifer eine View-Funktion, die den aktuellen Wechselkurs berechnet, bevor diese Reserven vollständig angepasst sind, erneut aufrufen kann, könnte er einen vorübergehend verzerrten Preis erhalten. Dieser verzerrte Preis könnte dann verwendet werden, um einen nachfolgenden Handel zu einem vorteilhaften Kurs auszuführen, wodurch der Markt effektiv vorweggenommen oder manipuliert wird. Diese Beispiele veranschaulichen, dass die Schwachstelle oft aus einer Diskrepanz im Timing von Zustandsaktualisierungen und externen Aufrufen entsteht, die es einem Angreifer ermöglicht, einen inkonsistenten Zwischenzustand auszunutzen.

Häufige Missverständnisse

Eines der häufigsten Missverständnisse bezüglich Read-Only-Reentrancy ist die Annahme, dass "View-Funktionen von Natur aus sicher sind". Viele Entwickler gehen davon aus, dass View-Funktionen, da sie den Zustand des Vertrags nicht ändern, nicht in einem Reentrancy-Angriff ausgenutzt werden können. Dies ist eine gefährliche Vereinfachung. Während View-Funktionen selbst den Zustand nicht ändern, lesen sie den Zustand. Wenn der Zustand, den sie lesen, aufgrund eines laufenden externen Aufrufs vorübergehend inkonsistent ist, kann der zurückgegebene Wert manipuliert werden, was schwerwiegende Folgen für die abhängige Logik haben kann. Die Sicherheit einer View-Funktion hängt von der Integrität und Konsistenz der Daten ab, auf die sie zugreift, insbesondere während komplexer Transaktionsabläufe.

Ein weiteres häufiges Missverständnis ist, dass "Reentrancy-Guards vor allen Reentrancy-Angriffen schützen." Während Muster wie das "Checks-Effects-Interactions"-Muster und Reentrancy-Guards (z.B. nonReentrant-Modifikatoren) sehr effektiv gegen traditionelle Reentrancy-Angriffe sind, die darauf abzielen, zustandsändernde Funktionen wiederholt auszuführen, adressieren sie Read-Only-Reentrancy oft nicht direkt. Ein nonReentrant-Guard verhindert typischerweise, dass eine Funktion erneut aufgerufen wird, während sie bereits ausgeführt wird. Ein Read-Only-Reentrancy-Angriff könnte jedoch eine andere View-Funktion angreifen, die keinen solchen Guard hat, oder er könnte ein Zeitfenster zwischen den "Effects"- und "Interactions"-Phasen ausnutzen, in dem der Zustand vorübergehend inkonsistent ist, aber keine explizite Reentrancy an der geschützten Funktion selbst erkannt wird. Das Problem ist nicht die erneute Ausführung derselben Funktion, sondern das Lesen eines Zwischenzustands.

Schließlich könnten einige Read-Only-Reentrancy als "theoretische oder Nischen-Schwachstelle" abtun. Diese Perspektive unterschätzt ihre tatsächlichen Auswirkungen. Wie Sicherheitsberichte hervorheben, hat diese Schwachstellenklasse erhebliche Gelder gefährdet. Die zunehmende Komplexität und Vernetzung von DeFi-Protokollen bedeutet, dass subtile, zeitabhängige Fehler wie Read-Only-Reentrancy wahrscheinlicher und wirkungsvoller werden. Es handelt sich nicht um einen theoretischen Grenzfall, sondern um ein praktisches Problem, das während der Design- und Auditphasen, insbesondere für Protokolle, die sich für kritische Daten auf externe Aufrufe und Inter-Contract-Kommunikation verlassen, strenge Aufmerksamkeit erfordert.

Zusammenfassung

Read-Only-Reentrancy stellt eine ausgeklügelte und oft unterschätzte Smart-Contract-Schwachstelle dar, die temporäre Inkonsistenzen im Zustand eines Vertrags während externer Aufrufe ausnutzt. Im Gegensatz zu ihrem traditionellen Gegenstück, das sich auf wiederholte Zustandsänderungen konzentriert, nutzt diese Variante View-Funktionen, um manipulierte oder veraltete Daten auszulesen und kritische Entscheidungsprozesse in abhängigen Verträgen zu beeinflussen. Der Angriffsvektor beinhaltet typischerweise einen externen Aufruf, der den Vertrag eines Angreifers auslöst, welcher dann den Opfervertrag erneut aufruft, um eine View-Funktion abzufragen, bevor die Zustandsvariablen des Opfers vollständig aktualisiert sind.

Die Auswirkungen auf das dezentrale Finanzwesen sind erheblich und können zu Preismanipulationen, falschen Sicherheitenbewertungen und erheblichen finanziellen Verlusten für Benutzer und Protokolle führen. Ihre Subtilität macht sie bei Standard-Sicherheitsaudits schwer erkennbar, und gängige Reentrancy-Minderungstechniken können sie möglicherweise nicht vollständig adressieren. Das Verständnis von Read-Only-Reentrancy ist für Entwickler und Auditoren von größter Bedeutung, um widerstandsfähige Smart Contracts zu erstellen, und für Benutzer, um die zugrunde liegenden Risiken im DeFi-Ökosystem zu verstehen. Robuste Sicherheitspraktiken, einschließlich sorgfältiger Reihenfolge der Operationen, gründlicher Zustands-Konsistenzprüfungen und umfassender Audits, sind unerlässlich, um sich vor dieser heimtückischen Bedrohung zu schützen.