Dornen in der Rose: Sicherheitsrisiken in Uniswap v4's Hook-Mechanismus

Uniswap v4 ist auf dem Weg! Das Team hat ehrgeizige Pläne, eine Vielzahl neuer Funktionen [1] einzuführen, darunter (theoretisch) eine unbegrenzte Anzahl von Pools und dynamische Gebührenraten für jedes Handelspaar, Singleton, Flash-Accounting, Hooks und Unterstützung für ERC1155. Durch die Nutzung des transienten Speichers, der durch EIP-1153 eingeführt wurde, wird erwartet, dass Uniswap v4 nach dem Cancun-Upgrade von Ethereum gestartet wird.

Unter diesen Innovationen hat der Hook-Mechanismus aufgrund seines mächtigen Potenzials viel Aufmerksamkeit erregt. Er ermöglicht die Ausführung spezifischer Codes zu bestimmten Zeitpunkten während des Betriebs eines Pools, was die Erweiterbarkeit und Flexibilität der Pools erheblich verbessert.

Der Hook-Mechanismus kann jedoch auch ein zweischneidiges Schwert sein. Während er leistungsstark und flexibel ist, darf die Herausforderung der sicheren Nutzung nicht übersehen werden. Diese Komplexität eröffnet unweigerlich neue potenzielle Angriffsvektoren. Mit dem Ziel, aus Sicherheitsperspektive zur Community beizutragen, ist es unser Ziel, eine Reihe von Artikeln zu präsentieren, die die mit diesem Mechanismus verbundenen Sicherheitsprobleme und Bedenken systematisch untersuchen. Wir glauben, dass diese Erkenntnisse Aufschluss über die Erstellung sicherer Uniswap v4 Hooks geben werden.

Dieser Artikel dient als erster in dieser Reihe und bietet unseren Lesern einen umfassenden Überblick und ein grundlegendes Verständnis. Bleiben Sie dran für weitere aufschlussreiche Diskussionen!

Der Mechanismus von Uniswap v4

Bevor wir ins Detail gehen, müssen wir ein grundlegendes Verständnis des Mechanismus von Uniswap v4 haben. Laut der offiziellen Ankündigung [1] und dem Whitepaper [2] sind Hooks, die Singleton-Architektur und das Flash-Accounting drei Schlüsselfunktionen, die die Pool-Anpassung und das effiziente Routing über viele Pools hinweg ermöglichen.

Hooks

Hooks in v4 sind so konzipiert, dass jeder Entscheidungen über Kompromisse durch Hooks treffen kann, bei denen es sich um Verträge handelt, die zu verschiedenen Zeitpunkten im Lebenszyklus einer Pool-Aktion ausgeführt werden. Dadurch ist es möglich, Pools anzupassen, die dynamische Gebühren nativ unterstützen, On-Chain-Limit-Orders hinzuzufügen oder als zeitgewichteter Durchschnitts-Markt-Maker (TWAMM) zu agieren, um große Orders über die Zeit zu verteilen.

Derzeit gibt es acht Hook-Callbacks, die in vier Gruppen unterteilt sind (jede Gruppe enthält ein Paar von Callbacks):

beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
beforeSwap/afterSwap
beforeDonate/afterDonate

Unten ist der Ablauf der Swap-Hooks aus dem Whitepaper [2] dargestellt.

Das Uniswap-Team hat einige Beispiele (z. B. den TWAMM Hook [3]) zur Veranschaulichung der Verwendung bereitgestellt, und die Community-Teilnehmer leisten ebenfalls ihren Beitrag. Die offiziellen Dokumente [4] verlinken auf das Repository Awesome Uniswap v4 Hooks [5], das weitere Hook-Beispiele sammelt.

Singleton, Flash-Accounting und Lock-Mechanismus

Die Singleton-Architektur und das Flash-Accounting sind darauf ausgelegt, die Leistung durch Kostenreduzierung und Gewährleistung von Effizienz zu verbessern. Insbesondere wird ein neuer singleton-Vertrag eingeführt, in dem alle Pools innerhalb eines einzigen Smart Contracts leben. Dieses Singleton-Design basiert auf einem PoolManager zum Speichern und Verwalten aller Zustände für alle Pools.

Im Gegensatz zu früheren Versionen des Uniswap-Protokolls, bei denen Operationen wie Swaps oder Liquiditätsaddition direkte Token-Überweisungen beinhalteten, führt Uniswap v4 flash accounting zusammen mit einem lock mechanism ein.

Insbesondere funktioniert der Lock-Mechanismus wie folgt:

Ein Locker-Vertrag fordert einen Lock beim PoolManager an.
Der PoolManager fügt die Adresse des Lockers zur lockData-Warteschlange hinzu und ruft dessen lockAcquired-Callback auf.
Der Locker führt seine Logik im Callback aus. Während der Ausführung eines Lockers können seine Interaktionen mit Pools zu nicht-null Währungs-Deltas führen. Am Ende der Ausführung müssen jedoch alle Deltas auf null ausgeglichen sein. Außerdem, wenn die lockData-Warteschlange nicht leer ist, kann nur der letzte Locker Operationen durchführen.
Anschließend überprüft der PoolManager den Zustand der lockData-Warteschlange und der Währungs-Deltas. Nach der Verifizierung entfernt der PoolManager den Locker.

Zusammenfassend verhindert der Lock-Mechanismus gleichzeitigen Zugriff und gewährleistet den Ausgleich. Locker reihen sich für Locks ein und führen dann über den lockAcquired-Callback aus. Vor und nach Pool-Aktionen werden bestimmte Hook-Callbacks aufgerufen. Schließlich überprüft der PoolManager den Zustand.

Dieser Ansatz bedeutet, dass Operationen einen internen Netto-Saldo (d. h. Delta) anpassen, anstatt sofortige Überweisungen durchzuführen. Alle Änderungen werden im internen Saldo des Pools aufgezeichnet, wobei tatsächliche Überweisungen am Ende der Operation (d. h. Lock) stattfinden. Dieser Prozess garantiert keine ausstehenden Token und bewahrt so die Solvenz.

Aufgrund des Lock-Mechanismus kann ein EOA (External Owned Account) nicht direkt mit dem PoolManager interagieren. Stattdessen muss jede Interaktion über einen Vertrag erfolgen. Der Vertrag fungiert als zwischengeschalteter Locker, der einen Lock anfordert, bevor Pool-Aktionen durchgeführt werden. Es gibt hauptsächlich zwei Szenarien der Vertragsinteraktion:

Der Locker-Vertrag stammt aus dem offiziellen Repository oder wurde von Benutzern bereitgestellt. In diesen Fällen können wir die Interaktionen als über einen Router betrachten.
Der Locker und der Hook sind im selben Vertrag integriert oder werden von einer Drittpartei gesteuert. In diesem Szenario können wir die Interaktionen als über einen Hook betrachten. Daher spielt der Hook eine doppelte Rolle als Locker und Callback-Handler.

Bedrohungsmodelle

Die Bedrohungsmodelle müssen ermittelt werden, bevor die entsprechenden Sicherheitsprobleme diskutiert werden. Grundsätzlich gibt es bestimmte Überlegungen, die bei der Verwendung von Hooks auftreten:

Bedrohungsmodell I: Die Hooks sind gutartig, aber anfällig.
Bedrohungsmodell II: Die Hooks sind bösartig.

In den folgenden Abschnitten werden wir potenzielle Sicherheitsprobleme/Bedenken basierend auf den Bedrohungsmodellen diskutieren.

Sicherheitsbedenken in Bedrohungsmodell I

Bedrohungsmodell I konzentriert sich auf Schwachstellen, die mit den Hooks selbst zusammenhängen. Offensichtlich geht dieses Bedrohungsmodell davon aus, dass die Entwickler und ihre Hooks gutartig sind. Vorhandene bekannte Schwachstellen von Smart Contracts könnten jedoch auch in den Hooks auftreten. Wenn der Hook beispielsweise als upgradefähiger Vertrag implementiert ist, kann er anfällig für einige Schwachstellen sein, die denen der UUPSUpgradeable-Schwachstelle der OZ-Bibliothek [6] ähneln.

Angesichts dieser Überlegungen konzentrieren wir uns auf potenzielle Schwachstellen, die spezifisch für v4 sind. Insbesondere in Uniswap v4 sind Hooks anpassbare Smart Contracts, die Logik vor oder nach den Kern-Pool-Aktionen (einschließlich initialize, modifyPosition, swap und donate) ausführen können. Hooks sollen die Standard-Hook-Schnittstelle implementieren, dürfen aber auch benutzerdefinierte Logik enthalten. Daher beschränkt sich unser Umfang auf die Logik, die mit der Standard-Hook-Schnittstelle verbunden ist. Wir können dann zusammenfassen, wie Hooks wahrscheinlich diese Standard-Hook-Funktionen verwenden, um potenzielle Quellen von Schwachstellen zu identifizieren.

Im Allgemeinen können Hooks in zwei Kategorien fallen:

Hooks, die als Verwahrer von Benutzergeldern fungieren. In diesen Fällen können Angreifer den Hook ins Visier nehmen, um Gelder zu übertragen, was zu Vermögensverlusten führt.
Hooks, die kritische Zustandsdaten speichern, auf die Benutzer oder andere Protokolle angewiesen sind. Für diese Hooks können Angreifer kritische Zustände absichtlich ändern. Die fehlerhaften Zustände können, wenn sie von anderen Benutzern oder Protokollen verwendet werden, potenzielle Risiken einführen.

Beachten Sie, dass Hooks, die nicht in diese beiden Kategorien fallen, nicht in unserem Umfang liegen.

Trotz des begrenzten Umfangs ist es immer noch nicht machbar, hier alle Möglichkeiten aufzuzählen. Da zum Zeitpunkt der Erstellung dieses Textes keine tatsächlichen Anwendungen vorhanden sind, entscheiden wir uns dafür, das Awesome Uniswap v4 Hooks-Repository zu untersuchen, um Einblicke zu gewinnen.

Nach sorgfältiger Prüfung des Repositorys (mit Commit-Hash 3a0a444922f26605ec27a41929f3ced924af6075) haben wir mehrere kritische Schwachstellen identifiziert. Diese stammen hauptsächlich von den riskanten Interaktionen zwischen Hooks, PoolManager und externen Drittanbietern. Die Schwachstellen fallen in zwei Hauptkategorien: fehlerhafte Zugriffskontrolle und unzureichende Eingabevalidierung. Die Ergebnisse sind in der folgenden Tabelle zusammengefasst:

# fehlerhafter Projekte	# fehlerhafte Zugriffskontrolle	# unzureichende Eingabevalidierung
8	6	2

Insgesamt haben wir 22 relevante Projekte identifiziert (ohne einige, die nicht mit Uniswap v4 in Verbindung zu stehen schienen). Davon wurden 8 (oder 36 %) als anfällig eingestuft. Insbesondere wurde bei 6 dieser anfälligen Projekte eine fehlerhafte Zugriffskontrolle festgestellt, während 2 anfällig für nicht vertrauenswürdige externe Aufrufe waren.

Fehlerhafte Zugriffskontrolle

In dieser Diskussion konzentrieren wir uns auf Probleme mit der Zugriffskontrolle im Zusammenhang mit v4, die sich aus den Callback-Funktionen von v4 ergeben, zu denen 8 Hook-Callbacks und der Lock-Callback gehören. Natürlich müssen auch andere Fälle überprüft werden. Diese Fälle hängen jedoch vom Design ab, was außerhalb des von unserer früheren Diskussion definierten Umfangs liegt.

Diese Funktionen sollten nur vom PoolManager aufgerufen werden, nicht von anderen Adressen (einschließlich EOAs und Verträgen). Betrachten Sie zum Beispiel eine Situation, in der eine Belohnung vom Pool-Schlüssel verteilt wird. Wenn die entsprechende Funktion von beliebigen Konten aufgerufen werden kann, könnte die Belohnung versehentlich beansprucht werden.

Daher ist es entscheidend, robuste Zugriffskontrollmechanismen für Hooks einzurichten, insbesondere da sie von anderen Parteien als dem Pool selbst aufgerufen werden können. Durch sorgfältiges Management von Zugriffsberechtigungen können Pools das Risiko von unbefugten oder bösartigen Interaktionen mit den Hooks erheblich minimieren.

Unzureichende Eingabevalidierung

In Uniswap v4 müssen Benutzer aufgrund des Lock-Mechanismus einen Lock über einen Vertrag erwerben, bevor sie Pool-Aktionen ausführen können. Dies stellt sicher, dass der aktuell interagierende Vertrag der letzte Locker ist.

Trotzdem besteht ein potenzielles Angriffsszenario, nämlich nicht vertrauenswürdige externe Aufrufe aufgrund unzureichender Eingabevalidierung in einigen anfälligen Hook-Implementierungen:

Erstens validiert der Hook nicht den Pool, mit dem Benutzer interagieren möchten. Dies könnte ein bösartiger Pool mit gefälschten Token sein, der schädliche Logik ausführt.
Zweitens erlauben einige entscheidende Hook-Funktionen beliebige externe Aufrufe.

Nicht vertrauenswürdige externe Aufrufe sind äußerst gefährlich, da sie zu verschiedenen Arten von Angriffen führen können, einschließlich der bekannten Reentrancy-Probleme.

Um solche anfälligen Hooks auszunutzen, könnte ein Angreifer einen bösartigen Pool für seine gefälschten Token registrieren und dann den Hook aufrufen, um Aktionen auf dem Pool auszuführen. Bei der Interaktion mit dem Pool übernimmt die bösartige Token-Logik die Kontrolle, um Fehlverhalten zu ermöglichen.

Abhilfemaßnahmen für Bedrohungsmodell I

Um solche Probleme mit Hooks zu umgehen, ist es unerlässlich, Interaktionen zu validieren, indem für sensible externe/öffentliche Funktionen angemessene Zugriffskontrollen und für Eingabeargumente Überprüfungen durchgesetzt werden. Außerdem kann ein Reentrancy-Guard hilfreich sein, um sicherzustellen, dass der Hook nicht wiederholt innerhalb des standardmäßigen Logikflusses ausgeführt werden kann. Durch die Implementierung geeigneter Schutzmaßnahmen können Pools die mit dieser Art von Bedrohung verbundenen Risiken mindern.

Sicherheitsbedenken in Bedrohungsmodell II

In diesem Bedrohungsmodell wird davon ausgegangen, dass die Entwickler und ihre Hooks bösartig sind. Angesichts der Fülle von Möglichkeiten haben wir uns hauptsächlich auf Probleme im Zusammenhang mit v4 konzentriert. Folglich ist die wichtigste Überlegung, ob die bereitgestellten Hooks die vom Benutzer übertragenen oder genehmigten Krypto-Assets verarbeiten können.

Je nach Methode des Zugriffs auf die Hooks, die die potenziellen Berechtigungen der Hooks bestimmt, können wir Hooks in zwei verschiedene Kategorien einteilen:

Verwaltete Hooks: Hooks sind nicht der Einstiegspunkt. Benutzer müssen über einen Router, wahrscheinlich von Uniswap bereitgestellt, mit den Hooks interagieren.
Eigenständige Hooks: Hooks sind der Einstiegspunkt und ermöglichen Benutzern die direkte Interaktion mit ihnen.

Abbildung 2: Beispiele für bösartige Hooks

Verwaltete Hooks

Im Fall von verwalteten Hooks werden die Krypto-Assets der Benutzer (einschließlich nativer Token und anderer) an den router übertragen oder genehmigt. Aufgrund der vom PoolManager erzwungenen Saldenprüfung ist es für bösartige Hooks nicht einfach, diese Assets direkt zu stehlen.

Potenzielle Angriffsflächen bestehen jedoch weiterhin. Beispielsweise könnte der Gebührenverwaltungsmechanismus in v4 potenziell von Angreifern über Hooks manipuliert werden.

Eigenständige Hooks

Die Situation wird komplexer, wenn Hooks in Form von eigenständigen Hooks als Einstiegspunkt verwendet werden. In diesem Szenario gewinnen Hooks mehr Macht, da Benutzer direkt mit ihnen interagieren können. Theoretisch können Hooks durch diese Interaktion jede gewünschte Aktion ausführen.

Unter dem v4-Szenario ist die Validierung der Code-Logik ein kritischer Punkt. Die Hauptsorge ist, ob die Code-Logik manipuliert werden kann. Hooks können als upgradefähig implementiert werden, was bedeutet, dass ein Hook, der als sicher erscheint, potenziell später zu einem bösartigen aufgerüstet werden könnte, was ein erhebliches Risiko darstellt. Dazu gehören:

Upgradefähige Proxys, die direkt ausgenutzt werden können;
Ausgestattet mit selbstzerstörender Logik, die durch die kombinierte Nutzung von selfdestruct und create2 ausgenutzt werden kann.

Abhilfemaßnahmen für Bedrohungsmodell II

Es ist unerlässlich zu beurteilen, ob die Hooks bösartig sind. Insbesondere für verwaltete Hooks sollten wir uns auf das Verhalten der Gebührenverwaltung konzentrieren; für eigenständige Hooks besteht die Hauptsorge darin, ob sie aufrüstbar sind oder nicht.

Fazit

In diesem Artikel geben wir zunächst eine kurze Zusammenfassung der Kernmechanismen von Uniswap v4, die sich auf die Sicherheitsprobleme der v4-Hooks beziehen. Danach definieren wir zwei Bedrohungsmodelle und bieten eine High-Level-Diskussion über ihre jeweiligen Sicherheitsprobleme. In den kommenden Artikeln dieser Reihe werden wir detaillierte Analysen dieser Sicherheitsprobleme unter jedem Bedrohungsmodell liefern. Bleiben Sie dran!