Ich glaube, dass Uniswap v4 bald für alle verfügbar sein wird!

Dieses Mal hat das Uniswap-Team ehrgeizige Ziele und plant die Einführung vieler neuer Funktionen [1], darunter die Unterstützung einer unbegrenzten Anzahl von Liquiditätspools und dynamischen Gebühren pro Handelspaar, Singleton-Design, Lightning Accounting, Hooks und Unterstützung für den ERC1155-Token-Standard . Uniswap v4 nutzt den durch EIP-1153 eingeführten vorübergehenden Speicher und wird voraussichtlich nach dem Ethereum Cancun-Upgrade veröffentlicht.

Unter vielen Innovationen hat der Hook-Mechanismus aufgrund seines leistungsstarken Potenzials große Aufmerksamkeit erregt. Der Hook-Mechanismus unterstützt die Ausführung von spezifischem Code an bestimmten Punkten im Lebenszyklus des Liquiditätspools und verbessert so die Skalierbarkeit und Flexibilität des Pools erheblich.

Der Hakenmechanismus kann jedoch auch ein zweischneidiges Schwert sein. Obwohl es leistungsstark und flexibel ist, ist die sichere Verwendung von Hook auch eine große Herausforderung. Die Komplexität von Hooks bringt zwangsläufig neue potenzielle Angriffsvektoren mit sich. Daher hoffen wir, eine Reihe von Artikeln zu schreiben, um die Sicherheitsprobleme und potenziellen Risiken im Zusammenhang mit dem Hook-Mechanismus systematisch vorzustellen und so die Sicherheitsentwicklung der Community zu fördern. Wir glauben, dass diese Erkenntnisse zum Aufbau eines sicheren Uniswap v4 Hook beitragen werden.

Als Beginn dieser Artikelserie stellt dieser Artikel Konzepte im Zusammenhang mit dem Hook-Mechanismus in Uniswap v4 vor und skizziert die Sicherheitsrisiken des Hook-Mechanismus.

Der Mechanismus von Uniswap V4

Bevor wir eintauchen, müssen wir ein grundlegendes Verständnis der Mechanismen von Uniswap v4 haben. Laut der offiziellen Ankündigung [1] und dem Whitepaper [2] sind Hooks, Singleton-Architektur und Lightning Accounting drei wichtige Funktionen, um benutzerdefinierte Liquiditätspools zu implementieren und ein effizientes Routing über mehrere Pools hinweg zu erreichen.

1.1 Haken

Hooks beziehen sich auf Verträge, die in verschiedenen Phasen des Liquiditätspool-Lebenszyklus laufen. Das Uniswap-Team hofft, durch die Einführung von Hooks jedem die Möglichkeit zu geben, Kompromissentscheidungen zu treffen. Auf diese Weise ist es möglich, dynamische Gebühren nativ zu unterstützen, On-Chain-Price-Cap-Orders hinzuzufügen oder große Orders über einen Time-Weighted Average Market Maker (TWAMM) zu verteilen.

Derzeit gibt es acht Hook-Rückrufe, die in vier Gruppen unterteilt sind (jede Gruppe enthält ein Rückrufpaar):

  • vorInitialisieren/nachInitialisieren

  • vorÄndernPosition/nachÄndernPosition

  • vorSwap/nachSwap

  • vorSpende/nachSpende

Das Folgende ist der im Whitepaper [2] vorgestellte Prozess des Austauschs von Hooks.

Abbildung 1: Exchange-Hook-Prozess

Das Uniswap-Team stellte die Vorgehensweise anhand einiger Beispiele vor (z. B. TWAMM Hook[3]), und Community-Teilnehmer leisteten auch einige Beiträge. Die offizielle Dokumentation[4] verlinkt auch auf das Awesome Uniswap v4 Hooks[5]-Repository, das weitere Hook-Beispiele sammelt.

1.2 Singleton, Lightning Accounting und Sperrmechanismus

Die Singleton-Architektur und das Flash-Accounting sollen die Leistung verbessern, indem sie die Kosten senken und die Effizienz gewährleisten. Es führt einen neuen Singleton-Vertrag ein, bei dem alle Liquiditätspools im selben Smart Contract gehalten werden. Dieses Singleton-Design basiert auf einem PoolManager, um den Status aller Pools zu speichern und zu verwalten.

In früheren Versionen des Uniswap-Protokolls umfassten Vorgänge wie der Austausch oder das Hinzufügen von Liquidität direkte Token-Transfers. Die v4-Version unterscheidet sich dadurch, dass sie Lightning Accounting und einen Sperrmechanismus einführt.

Der Verriegelungsmechanismus funktioniert wie folgt:

1. Ein Schließfachvertrag fordert eine Sperre für PoolManager an.

2. PoolManager fügt die Adresse des Schließfachvertrags zur lockData-Warteschlange hinzu und ruft seinen lockAcquired-Rückruf auf.

3. Der Locker-Vertrag führt seine Logik im Rückruf aus. Während der Ausführung kann die Interaktion des Schließfachvertrags mit dem Pool zu Währungserhöhungen ungleich Null führen. Am Ende der Ausführung müssen sich jedoch alle Deltas auf Null einstellen. Wenn die lockData-Warteschlange nicht leer ist, kann außerdem nur der letzte Schließfachvertrag Vorgänge ausführen.

4. PoolManager prüft den Status der lockData-Warteschlange und das Währungsinkrement. Nach der Überprüfung löscht PoolManager den Schließfachvertrag.

Zusammenfassend verhindert der Sperrmechanismus den gleichzeitigen Zugriff und stellt sicher, dass alle Transaktionen gelöscht werden können. Der Locker-Vertrag gilt für Sperren nacheinander und führt dann Transaktionen über den lockAcquired-Rückruf aus. Der entsprechende Hook-Rückruf wird vor und nach jedem Poolvorgang ausgelöst. Abschließend prüft der PoolManager den Status.

Dieser Ansatz bedeutet, dass der Vorgang den internen Nettosaldo (d. h. Delta) anpasst, anstatt eine sofortige Überweisung durchzuführen. Alle Änderungen werden in der internen Bilanz des Pools erfasst und die tatsächliche Übertragung erfolgt am Ende des Vorgangs (d. h. der Sperrung). Durch diesen Prozess wird sichergestellt, dass keine ausstehenden Token vorhanden sind, wodurch die Integrität der Gelder gewahrt bleibt.

Aufgrund des Sperrmechanismus können External Ownership Accounts (EOA) nicht direkt mit PoolManager interagieren. Stattdessen muss jede Interaktion über einen Vertrag erfolgen. Dieser Vertrag fungiert als Zwischenschließfach und muss vor der Durchführung von Poolvorgängen eine Sperre anfordern.

Es gibt zwei Hauptszenarien für Vertragsinteraktionen:

  • Ein bestimmter Schließfachvertrag stammt aus der offiziellen Codebasis oder wird von Benutzern bereitgestellt. In diesem Fall können wir uns vorstellen, dass die Interaktion über den Router erfolgt.

  • Ein Schließfachvertrag und Hook sind in denselben Vertrag integriert oder werden von einer Drittpartei kontrolliert. In diesem Fall können wir uns vorstellen, dass die Interaktion über Hooks erfolgt. In diesem Fall übernimmt Hook sowohl die Rolle des Schließfachvertrags als auch die Verantwortung für die Bearbeitung von Rückrufen.

Bedrohungsmodell

Bevor wir damit verbundene Sicherheitsprobleme diskutieren, müssen wir das Bedrohungsmodell identifizieren. Wir betrachten hauptsächlich die folgenden zwei Situationen:

  • Bedrohungsmodell I: Hooks selbst sind harmlos, weisen jedoch Schwachstellen auf.

  • Bedrohungsmodell II: Hooks sind von Natur aus bösartig.

In den folgenden Abschnitten diskutieren wir potenzielle Sicherheitsprobleme basierend auf diesen beiden Bedrohungsmodellen.

2.1 Sicherheitsprobleme im Bedrohungsmodell I

Das Bedrohungsmodell I konzentriert sich auf Schwachstellen im Zusammenhang mit dem Hook selbst. Dieses Bedrohungsmodell geht davon aus, dass Entwickler und ihre Hooks harmlos sind. Es können jedoch auch bestehende bekannte Schwachstellen in Smart Contracts in Hooks auftauchen. Wenn ein Hook beispielsweise als aktualisierbarer Vertrag implementiert wird, können ähnliche Probleme wie die UUPSUpgradeable-Schwachstelle von OpenZeppelin auftreten.

Angesichts der oben genannten Faktoren haben wir uns entschieden, uns auf potenzielle Schwachstellen zu konzentrieren, die nur in der v4-Version auftreten. In Uniswap v4 sind Hooks intelligente Verträge, die benutzerdefinierte Logik vor oder nach Kernpooloperationen ausführen können, einschließlich Initialisierung, Positionsänderung, Austausch und Sammlung. Während von Hooks erwartet wird, dass sie Standardschnittstellen implementieren, ermöglichen sie auch die Einbindung benutzerdefinierter Logik. Daher wird sich unsere Diskussion auf die Logik beschränken, die die Standard-Hook-Schnittstelle umfasst. Wir werden dann versuchen, mögliche Schwachstellenquellen zu identifizieren, beispielsweise wie Hooks diese Standard-Hook-Funktionen missbrauchen könnten.

Konkret konzentrieren wir uns auf die folgenden zwei Arten von Hooks:

  • Der erste Haken besteht darin, Benutzergelder zu behalten. In diesem Fall kann ein Angreifer diesen Hook angreifen, um Gelder zu transferieren, was zu Vermögensverlusten führt.

  • Der zweite Hook-Typ speichert wichtige Statusdaten, auf die Benutzer oder andere Protokolle angewiesen sind. In diesem Fall versucht der Angreifer möglicherweise, den kritischen Zustand zu ändern. Potenzielle Risiken können entstehen, wenn andere Benutzer oder Protokolle einen falschen Status verwenden.

Bitte beachten Sie, dass Hooks außerhalb dieser beiden Bereiche nicht Gegenstand unserer Diskussion sind.

Da es zum Zeitpunkt des Verfassens dieses Artikels keine echten Anwendungsfälle für Hooks gibt, werden wir einige Informationen aus dem Awesome Uniswap v4 Hooks-Repository abrufen.

Nach einem tiefen Einblick in das Awesome Uniswap v4 Hooks-Repository (Commit-Hash 3a0a444922f26605ec27a41929f3ced924af6075) entdeckten wir mehrere kritische Schwachstellen. Diese Schwachstellen entstehen hauptsächlich durch riskante Interaktionen zwischen Hooks, PoolManager und externen Dritten und können hauptsächlich in zwei Kategorien unterteilt werden: Probleme bei der Zugriffskontrolle und Probleme bei der Eingabevalidierung. Spezifische Ergebnisse finden Sie in der folgenden Tabelle:

Insgesamt haben wir 22 relevante Projekte gefunden (ausgenommen Projekte, die nichts mit Uniswap v4 zu tun haben). Von diesen Projekten glauben wir, dass 8 (36 %) Projekte gefährdet sind. Von den acht anfälligen Projekten hatten sechs Probleme mit der Zugriffskontrolle und zwei waren anfällig für nicht vertrauenswürdige externe Anrufe.

2.1.1 Probleme mit der Zugangskontrolle

In diesem Teil der Diskussion konzentrieren wir uns hauptsächlich auf die Probleme, die durch die Callback-Funktionen in Version 4 verursacht werden können, einschließlich 8 Hook-Callbacks und Lock-Callbacks. Natürlich gibt es noch andere Situationen, die überprüft werden müssen, aber diese Situationen variieren je nach Design und gehen über den Rahmen unserer Diskussion hinaus.

Diese Funktionen sollten nur von PoolManager aufgerufen werden und können nicht von anderen Adressen (einschließlich EOA und Verträgen) aufgerufen werden. Wenn beispielsweise Belohnungen über Poolschlüssel verteilt werden, kann es sein, dass Belohnungen fälschlicherweise beansprucht werden, wenn die entsprechende Funktion von jedem Konto aufgerufen werden kann.

Daher ist es von entscheidender Bedeutung, starke Zugriffskontrollmechanismen für Hooks einzurichten, insbesondere da diese von anderen Parteien als dem Pool selbst aufgerufen werden können. Durch die strenge Verwaltung der Zugriffsrechte können Liquiditätspools das Risiko unbefugter oder böswilliger Interaktionen mit Hooks erheblich reduzieren.

2.1.2 Probleme bei der Eingabeüberprüfung

In Uniswap v4 müssen Benutzer aufgrund des Sperrmechanismus eine Sperre durch den Vertrag erhalten, bevor sie Fondspooloperationen durchführen können. Dadurch wird sichergestellt, dass der aktuell an der Interaktion beteiligte Vertrag der neueste Schließfachvertrag ist.

Dennoch gibt es immer noch ein mögliches Angriffsszenario, nämlich nicht vertrauenswürdige externe Aufrufe aufgrund einer fehlerhaften Eingabevalidierung in einigen anfälligen Hook-Implementierungen:

  • Erstens überprüft der Hook nicht den Geldpool, mit dem der Benutzer interagieren möchte. Dabei könnte es sich um einen bösartigen Pool handeln, der gefälschte Token enthält und schädliche Logik ausführt.

  • Zweitens ermöglichen einige Schlüssel-Hook-Funktionen beliebige externe Aufrufe.

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

Um diese anfälligen Hooks anzugreifen, kann ein Angreifer einen böswilligen Fund-Pool für seine eigenen gefälschten Token registrieren und dann den Hook aufrufen, um Vorgänge im Fund-Pool durchzuführen. Bei der Interaktion mit dem Pool kapert die bösartige Token-Logik den Kontrollfluss, um unerwünschtes Verhalten auszulösen.

2.1.3 Präventive Maßnahmen gegen Bedrohungsmodell I

Um solche Sicherheitsprobleme im Zusammenhang mit Hooks zu umgehen, ist es von entscheidender Bedeutung, Interaktionen zu authentifizieren, indem die erforderlichen Zugriffskontrollen für sensible externe/öffentliche Funktionen ordnungsgemäß durchgesetzt und Eingabeparameter validiert werden. Darüber hinaus kann der Wiedereintrittsschutz dazu beitragen, sicherzustellen, dass der Hook im Standardlogikfluss nicht wiederholt ausgeführt wird. Durch die Implementierung geeigneter Sicherheitsmaßnahmen können Pools die mit solchen Bedrohungen verbundenen Risiken verringern.

2.2 Sicherheitsprobleme im Bedrohungsmodell II

Bei diesem Bedrohungsmodell gehen wir davon aus, dass der Entwickler und sein Hook böswillig sind. Aufgrund des breiten Anwendungsbereichs konzentrieren wir uns nur auf Sicherheitsprobleme im Zusammenhang mit der v4-Version. Daher kommt es darauf an, ob der bereitgestellte Hook mit den vom Benutzer übertragenen oder autorisierten Krypto-Assets umgehen kann.

Da die Zugriffsmethode auf den Hook die Berechtigungen bestimmt, die dem Hook gewährt werden können, unterteilen wir den Hook in zwei Kategorien:

  • Verwaltete Hooks: Hooks sind keine Einstiegspunkte. Benutzer müssen über einen Router (möglicherweise von Uniswap bereitgestellt) mit dem Hook interagieren.

  • Eigenständige Hooks: Hooks sind Einstiegspunkte, die es Benutzern ermöglichen, direkt mit ihnen zu interagieren.

Abbildung 2: Beispiel eines bösartigen Hooks

2.2.1 Verwalteter Hook

In diesem Fall werden die Krypto-Assets des Benutzers (einschließlich nativer Token und anderer Token) an den Router übertragen oder autorisiert. Da PoolManager Kontostandprüfungen durchführt, ist es für böswillige Hooks nicht einfach, diese Vermögenswerte direkt zu stehlen. Allerdings gibt es immer noch eine potenzielle Angriffsfläche. Beispielsweise kann der Kostenverwaltungsmechanismus der v4-Version von Angreifern über Hooks manipuliert werden.

2.2.2 Unabhängiger Haken

Noch komplizierter ist die Situation, wenn Hooks als Einstiegspunkte verwendet werden. In diesem Fall erhält der Hook mehr Leistung, da der Benutzer direkt mit ihm interagieren kann. Theoretisch kann ein Hook mit dieser Interaktion alles machen, was er will.

In der v4-Version ist die Überprüfung der Codelogik sehr wichtig. Die Hauptfrage ist, ob die Codelogik manipuliert werden kann. Wenn ein Hook aktualisierbar ist, bedeutet dies, dass ein scheinbar sicherer Hook nach dem Upgrade bösartig werden kann, was ein erhebliches Risiko darstellt. Zu diesen Risiken gehören:

  • Aktualisierbare Agenten (können direkt angegriffen werden);

  • Mit Selbstzerstörungslogik. Es kann angegriffen werden, wenn selfdestruct und create2 gemeinsam aufgerufen werden.

2.2.3 Vorbeugende Maßnahmen gegen Bedrohungsmodell II

Es ist wichtig zu beurteilen, ob der Hook bösartig ist. Insbesondere bei verwalteten Hooks sollten wir uns auf das Verhalten der Gebührenverwaltung konzentrieren, während bei eigenständigen Hooks das Hauptaugenmerk darauf liegt, ob sie aktualisierbar sind.

abschließend

In diesem Artikel geben wir zunächst einen kurzen Überblick über die Kernmechanismen im Zusammenhang mit den Hook-Sicherheitsproblemen von Uniswap v4. Anschließend schlagen wir zwei Bedrohungsmodelle vor und skizzieren kurz die damit verbundenen Sicherheitsrisiken.

In den folgenden Artikeln werden wir eine eingehende Analyse der Sicherheitsprobleme bei jedem Bedrohungsmodell durchführen.