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

Uniswap v4 ist auf dem Weg! Das Team hat ehrgeizige Pläne, eine Reihe 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 von EIP-1153 eingeführten transienten Speichers wird erwartet, dass Uniswap v4 nach dem Cancun-Upgrade von Ethereum gestartet wird.

Unter diesen Innovationen erregt der Hook-Mechanismus aufgrund seines leistungsstarken Potenzials große Aufmerksamkeit. Er ermöglicht die Ausführung spezifischen Codes an bestimmten Punkten 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 zwangsläufig neue potenzielle Angriffsvektoren. Mit dem Ziel, aus Sicherheitsperspektive einen Beitrag zur Community zu leisten, ist es unser Ziel, eine Reihe von Artikeln zu präsentieren, die die Sicherheitsprobleme und Bedenken im Zusammenhang mit diesem Mechanismus systematisch untersuchen. Wir glauben, dass diese Erkenntnisse Aufschluss über die Entwicklung sicherer Uniswap v4 Hooks geben werden.

Dieser Artikel dient als erster Teil 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 uns mit den Details befassen, 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 Flash Accounting drei Schlüsselfunktionen, die die Pool-Anpassung und effizientes Routing über viele Pools hinweg ermöglichen.

Hooks

Hooks in v4 sind so konzipiert, dass jeder über Hooks, Verträge, die an verschiedenen Punkten im Lebenszyklus einer Poolaktion ausgeführt werden, Entscheidungen treffen kann. Dadurch ist es möglich, Pools anzupassen, die dynamische Gebühren nativ unterstützen, On-Chain-Limit-Orders hinzuzufügen oder als Time-Weighted Average Market Maker (TWAMM) zu fungieren, 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

Das Folgende zeigt den Ablauf der vom Whitepaper [2] bereitgestellten Swap-Hooks.

Die Uniswap-Mannschaft hat einige Beispiele (z. B. den TWAMM Hook [3]) zur Veranschaulichung der Verwendung bereitgestellt, und auch die Teilnehmer der Community leisten ihren Beitrag. Die offizielle Dokumentation [4] verlinkt zum 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 Effizienzsicherung zu verbessern. Insbesondere wird ein neuer singleton-Vertrag eingeführt, in dem alle Pools innerhalb eines einzigen Smart Contracts leben. Dieses Singleton-Design stützt sich auf einen PoolManager zur Speicherung und Verwaltung aller Zustände für alle Pools.

Im Gegensatz zu früheren Versionen des Uniswap-Protokolls, bei denen Operationen wie Swapping oder Liquiditätszugabe direkte Token-Übertragungen 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ährungsdeltas führen. Am Ende der Ausführung müssen jedoch alle Deltas auf null gesetzt werden. Außerdem kann bei nicht leerer lockData-Warteschlange nur der letzte Locker Operationen durchführen.
Anschließend prüft der PoolManager den Zustand der lockData-Warteschlange und der Währungsdeltas. Nach der Überprüfung entfernt der PoolManager den Locker.

Zusammenfassend lässt sich sagen, dass der Lock-Mechanismus gleichzeitigen Zugriff verhindert und die Abrechnung sicherstellt. Locker werden für Locks angestellt und führen dann über den lockAcquired-Callback aus. Vor und nach Pool-Aktionen werden bestimmte Hook-Callbacks aufgerufen. Schließlich prüft der PoolManager den Zustand.

Dieser Ansatz bedeutet, dass Operationen einen internen Netto-Saldo (d. h. Delta) anpassen, anstatt sofortige Überweisungen durchzuführen. Alle Modifikationen werden im internen Saldo des Pools aufgezeichnet, wobei tatsächliche Überweisungen am Ende der Operation (d. h. Lock) erfolgen. Dieser Prozess garantiert keine offenen Token und erhält somit die Solvenz.

Aufgrund des Lock-Mechanismus kann eine EOA (Externally Owned Account) nicht direkt mit dem PoolManager interagieren. Stattdessen muss jede Interaktion über einen Vertrag laufen. Der Vertrag fungiert als Zwischen-Locker, um vor allen Pool-Aktionen einen Lock anzufordern. Es gibt hauptsächlich zwei Vertragsszenarien für die Interaktion:

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 kontrolliert. In diesem Szenario können wir die Interaktionen als über einen Hook betrachten. Daher spielt der Hook die Doppelrolle des Lockers und des Callback-Handlers.

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.

Sicherheitsprobleme im Bedrohungsmodell I

Bedrohungsmodell I konzentriert sich auf Schwachstellen im Zusammenhang mit den Hooks selbst. 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 upgradebarer Vertrag implementiert ist, kann er Schwachstellen aufweisen, die 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 Kern-Pool-Aktionen (einschließlich initialize, modifyPosition, swap und donate) ausführen können. Von Hooks wird erwartet, dass sie die Standard-Hook-Schnittstelle implementieren, aber sie dürfen auch angepasste 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 diese Standard-Hook-Funktionen wahrscheinlich verwenden, um potenzielle Schwachstellenquellen 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 anvisieren, um Gelder zu übertragen, was zu Vermögensverlusten führt.
Hooks, die kritische Zustandsdaten speichern, auf die sich Benutzer oder andere Protokolle verlassen. Bei diesen Hooks können Angreifer kritische Zustände absichtlich ändern. Die fehlerhaften Zustände führen, wenn sie von anderen Benutzern oder Protokollen verwendet werden, zu potenziellen Risiken.

Beachten Sie, dass Hooks, die nicht in diese beiden Kategorien fallen, nicht im Rahmen unserer Diskussion stehen.

Trotz des begrenzten Umfangs ist es hier immer noch nicht möglich, alle Möglichkeiten aufzuzählen. Da zum Zeitpunkt der Erstellung dieses Artikels noch keine tatsächlichen Anwendungen existieren, entscheiden wir uns, das Awesome Uniswap v4 Hooks-Repository nach einigen Erkenntnissen zu durchsuchen.

Nach sorgfältiger Prüfung des Repositories (mit Commit-Hash 3a0a444922f26605ec27a41929f3ced924af6075) haben wir mehrere kritische Schwachstellen identifiziert. Diese rühren hauptsächlich von riskanten Interaktionen zwischen Hooks, PoolManager und externen Dritten her. Die Schwachstellen fallen in zwei Hauptkategorien: fehlerhafte Zugriffskontrolle und unsachgemäße Eingabevalidierung. Die Ergebnisse sind in der folgenden Tabelle zusammengefasst:

# fehlerhafter Projekte	# fehlerhafte Zugriffskontrolle	# unsachgemäße Eingabevalidierung
8	6	2

Insgesamt identifizierten wir 22 relevante Projekte (ohne einige, die nicht mit Uniswap v4 in Verbindung zu stehen schienen). Davon wurden 8 (oder 36 %) als anfällig eingestuft. Spezifisch 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 Zugriffskontrollprobleme 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 festgelegten Umfangs liegt.

Diese Funktionen sollten nur vom PoolManager aufgerufen werden, nicht von anderen Adressen (einschließlich EOAs und Verträgen). Betrachten Sie beispielsweise eine Situation, in der eine Belohnung vom Poolschlüssel verteilt wird. Wenn die entsprechende Funktion von beliebigen Konten aufgerufen werden kann, kann 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 Zugriffsrechten können Pools das Risiko unautorisierter oder bösartiger Interaktionen mit den Hooks erheblich minimieren.

Unsachgemäße Eingabevalidierung

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

Trotzdem besteht weiterhin ein potenzielles Angriffsszenario, d. h. nicht vertrauenswürdiger externer Aufruf aufgrund unsachgemäßer 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 sein, der gefälschte Token enthält und schädliche Logik ausführt.
Zweitens erlauben einige wichtige Hook-Funktionen beliebige externe Aufrufe.

Nicht vertrauenswürdige externe Aufrufe sind extrem 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 Logik des bösartigen Tokens den Kontrollfluss, 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 notwendige Zugriffskontrollen für sensible externe/öffentliche Funktionen ordnungsgemäß durchgesetzt und Eingabeargumente verifiziert werden. Außerdem kann eine Reentrancy-Schutzvorrichtung hilfreich sein, um sicherzustellen, dass der Hook nicht wiederholt innerhalb des Standard-Logikflusses ausgeführt werden kann. Durch geeignete Schutzmaßnahmen können Pools die mit dieser Art von Bedrohung verbundenen Risiken mindern.

Sicherheitsprobleme im Bedrohungsmodell II

In diesem Bedrohungsmodell wird davon ausgegangen, dass die Entwickler und ihre Hooks bösartig sind. Angesichts des breiten Spektrums an Möglichkeiten haben wir uns hauptsächlich auf Probleme im Zusammenhang mit v4 konzentriert. Folglich besteht die Hauptüberlegung darin, ob die bereitgestellten Hooks die von Benutzern übertragenen oder genehmigten Krypto-Assets verarbeiten können.

Basierend auf der Art und Weise, wie auf die Hooks zugegriffen wird, die die potenziellen Berechtigungen bestimmt, die den Hooks gewährt werden, können wir Hooks in zwei verschiedene Kategorien einteilen:

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

Verwaltete Hooks

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

Potenzielle Angriffsflächen bestehen jedoch weiterhin. Beispielsweise könnte der Gebührenmanagementmechanismus 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 erhalten 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 upgradebar implementiert werden, was bedeutet, dass ein Hook, der als sicher erscheint, möglicherweise später zu einem bösartigen aufgerüstet wird, was ein erhebliches Risiko darstellt. Dies beinhaltet:

Upgradeable Proxies, die direkt ausgenutzt werden können;
Ausgestattet mit selbstzerstörender Logik, die aufgrund der kombinierten Verwendung von selfdestruct und create2 ausgenutzt werden kann.

Abhilfemaßnahmen für Bedrohungsmodell II

Es ist wichtig zu beurteilen, ob die Hooks bösartig sind. Insbesondere für verwaltete Hooks sollten wir uns auf das Verhalten des Gebührenmanagements konzentrieren, während für eigenständige Hooks die Hauptsorge darin besteht, ob sie aufrüstbar sind oder nicht.

Schlussfolgerung

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