#4 GMX-Vorfall: Cross-Contract-Reentrancy umgeht vier Jahre alten Schutz

Am 9. Juli 2025 erlebte die dezentrale Perpetual-Plattform GMX einen Exploit [1, 2], der auf ihren V1-Vertrag im Arbitrum-Netzwerk abzielte und zu einem Verlust von rund 42 Millionen US-Dollar führte. Der Angreifer nutzte eine Cross-Contract-Reentrancy-Schwachstelle aus, um den GLP-Preis zu manipulieren, und nutzte dann den verzerrten Preis, um zugrunde liegende Vermögenswerte aus den Liquiditätspools von GMX V1 abzuziehen.

Hintergrund

GMX V1 [3] ist eine dezentrale Plattform für den Handel mit Perpetual-Kontrakten, die auf Arbitrum eingesetzt wird. Sie ermöglicht es Nutzern, Perpetual-Kontrakte auf mehreren Krypto-Assets mit Hebelwirkung auf eine erlaubnisfreie und nicht-verwahrte Weise zu handeln. GMX V1 folgt einem einzigen Multi-Asset-Pool-Design, bei dem die Liquidität für alle unterstützten Assets in einem einheitlichen Vault-System aggregiert wird.

Positionsverwaltung in GMX

Die Positionsverwaltung in GMX ist ein zweistufiger Prozess. Konkret erstellen Nutzer Erhöhungs-/Verringerungsaufträge durch Interaktion mit den Verträgen OrderBook oder PositionRouter. Anschließend führt das autorisierte Keeper-Konto die Aufträge der Nutzer aus, was die globalen Short-Daten im Vertrag ShortTracker und den entsprechenden Zustand des Vertrags Vault aktualisiert. Die folgenden beiden Abbildungen zeigen die beiden Ausführungspfade (die Pfade Orderbook-Ausführung und Router-Ausführung) für die Verwaltung von Positionen in GMX. In diesem Vorfall nutzte der Angreifer beide Pfade aus, um die globalen Short-Daten zu manipulieren und Gewinne zu realisieren.

Der Orderbook-Ausführungspfad

Der Router-Ausführungspfad

GMX Vault

Der Vertrag Vault in GMX ist für die Verwaltung der Positionen und Vermögenswerte der Nutzer verantwortlich (z. B. die Finalisierung von Gewinnen und Verlusten). Um bösartige Interaktionen zu vermeiden, ist der Vertrag Vault nur zugänglich, wenn das "Leverage-Fenster" geöffnet ist (d. h., die Variable isLeverageEnabled im Vertrag Vault ist über die Funktion Timelock.enableLeverage() auf true gesetzt). Diese Validierung erzwingt, dass die Auftragsausführung den festen Pfaden (Orderbook-Ausführung und Router-Ausführung) folgen muss.

GMX Short Tracker

Der Vertrag ShortTracker ist für die Verfolgung und Aktualisierung der globalen Short-Daten (z. B. der Variable globalShortAveragePrice) während der Auftragsausführung zuständig. Gemäß den Pfaden Orderbook-Ausführung und Router-Ausführung wird die Funktion updateGlobalShortData() des Vertrags ShortTracker vor der Ausführung der Nutzeraufträge aufgerufen, um die neuesten globalen Short-Daten zu synchronisieren. Dieser Schritt gewährleistet die korrekte Realisierung von Gewinnen und Verlusten für die Positionen der Nutzer.

Verringerung der WETH-Position

Im Gegensatz zu anderen Aufträgen wird bei der Verringerung der WETH-Position über den Pfad Orderbook-Ausführung die Funktion _transferOutETH() im Vertrag OrderBook aufgerufen, um WETH-Token abzuheben und die nativen ETH-Token an die Nutzer zu übertragen. Wenn der Empfänger _receiver ein Vertrag ist, kann sendValue() die fallback()-Funktion des Vertrags auslösen, was eine potenzielle Reentrancy-Schwachstelle einführt. In diesem Vorfall nutzte der Angreifer diese Reentrancy-Schwachstelle wiederholt aus, um erhebliche Gewinne zu erzielen.

GLP Token

Der GLP (GMX Liquidity Provider) Token repräsentiert die einheitlichen Anteile für verschiedene Vermögenswerte im Vertrags-Vault. Nutzer können Vermögenswerte bereitstellen und einlösen, indem sie GLPs prägen und verbrennen.

Der GLP-Preis kann anhand der folgenden Gleichungen berechnet werden:

$$\text{GLPPreis}=\frac{\text{AUM}}{\text{GLPTotalSupply}}\backslash text\{GLPPreis\}=\; \backslash frac\{\backslash text\{AUM\}\}\{\backslash text\{GLPTotalSupply\}\}$$

$$\text{AUM}=\sum _{i=asset[0]}^{assets}({\mathrm{\Delta }}_{\text{GlobalShort[i]}}+{\text{AUM}}_{\text{Other[i]}})\backslash text\{AUM\}\; =\; \backslash sum^\{assets\}\_\{i\; =\; asset[0]\}(\backslash Delta\_\{\backslash text\{GlobalShort[i]\}\}\; +\; \backslash text\{AUM\}\_\{\backslash text\{Other[i]\}\})$$

$${\mathrm{\Delta }}_{\text{GlobalShort[i]}}=\frac{\text{globalShortSize}\times (\text{AssetMarketPrice}-\text{globalShortAveragePrice})}{\text{globalShortAveragePrice}}\backslash Delta\_\{\backslash text\{GlobalShort[i]\}\}\; =\; \backslash frac\{\; \backslash text\{globalShortSize\}\; \backslash times\; (\backslash text\{AssetMarketPrice\}\; -\; \backslash text\{globalShortAveragePrice\}\; )\; \}\{\; \backslash text\{globalShortAveragePrice\}\; \}$$

Wo:

• GLPTotalSupply repräsentiert die Gesamtzahl der GLP-Token.
• AUM besteht aus den folgenden beiden Komponenten.
  • ${\mathrm{\Delta }}_{\text{GlobalShort}}\backslash Delta\_\{\backslash text\{GlobalShort\}\}$ repräsentiert den uPnL (d. h. unrealisierten Gewinn und Verlust) aller Short-Positionen.
  • ${\text{AUM}}_{\text{Other}}\backslash text\{AUM\}\_\{\backslash text\{Other\}\}$ repräsentiert die bereitgestellte Liquidität des LP plus den unrealisierten uPnL aller Long-Positionen. Dieser Term blieb während des Vorfalls vor der Gewinnrealisierung nahezu unverändert.
• AssetMarketPrice ist der Marktpreis (in USD) des zugrunde liegenden Vermögenswerts.
• globalShortSize ist die Summe (in USD) aller Short-Positionen.
• globalShortAveragePrice ist der durchschnittliche Einstiegspreis der aggregierten globalen Short-Position.

Bei diesem Vorfall hat der Angreifer globalShortAveragePrice verzerrt, um den GLP-Preis zu manipulieren und Gewinne zu erzielen.

Schwachstellenanalyse

Die Grundursache ist eine Cross-Contract-Reentrancy-Schwachstelle im Vertrag OrderBook. Wie im Hintergrund beschrieben, löst die Verringerung von WETH-Positionen über den Pfad Orderbook-Ausführung einen Low-Level-Fallback-Aufruf an den Empfänger über _transferOutETH() aus. Die Funktion trägt einen nonReentrant-Modifier, aber dieser Schutz verhindert nur Reentrancy innerhalb des OrderBook-Vertrags selbst, nicht aber Cross-Contract-Aufrufe an den Vault.

Unter normalen Betriebsbedingungen kann die increasePosition()-Funktion des Vault nur über PositionRouter und PositionManager aufgerufen werden, die ShortTracker aufrufen, um globalShortAveragePrice vor jeder Positionsänderung zu aktualisieren. Der Angreifer erstellte Aufträge mit einem bösartigen Vertrag als Empfänger und rief während des Fallback-Aufrufs direkt increasePosition() auf dem Vault auf, wodurch PositionRouter/PositionManager und die zugehörige ShortTracker-Aktualisierung umgangen wurden. Durch wiederholtes Eröffnen und Schließen von Short-Positionen ohne Aktualisierung von globalShortAveragePrice verzerrte der Angreifer die Variable schrittweise. Der verzerrte Wert blähte den GLP-Preis auf, was es dem Angreifer ermöglichte, durch Prägen und Einlösen von GLPs Gewinne zu erzielen.

Angriffsanalyse

Der Angreifer startete eine Reihe von Transaktionen, die die globalen Short-Daten manipulierten und den Gewinn realisierten. Insbesondere konnte dieser Vorfall in drei Phasen unterteilt werden: Vorbereitung, Preismanipulation und Gewinnrealisierung. Alle zugehörigen Transaktionen sind in der folgenden Tabelle aufgeführt.

Vorbereitungsphase

1. (Tx 1) Der Angreifer stellte den Angriffskontrakt bereit, der während der Auftragsausführung als Vermögenswertempfänger verwendet wurde. Der Angriffskontrakt enthielt eine bösartige fallback()-Funktion.

2. (Tx 2) Der Angreifer erstellte im Vertrag OrderBook einen WETH-Long-Order für den Angriffskontrakt.

   

3. (Tx 3) Ein Keeper führte den Angreiferauftrag (aus Schritt 2) aus, der eine WETH-Long-Position für den Angriffskontrakt eröffnete. (Tx 3).

   

4. (Tx 4) Der Angreifer erstellte im Vertrag OrderBook einen WETH-Long-Verringerungsorder für den Angriffskontrakt.

   

Manipulationsphase

5. (Tx 5) Ein Keeper führte den vom Angriffskontrakt erstellten WETH-Long-Verringerungsorder (aus Schritt 4) über den Pfad Orderbook-Ausführung aus. Der Ausführungspfad rief _transferOutETH() auf, was die bösartige fallback()-Funktion im Angriffskontrakt auslöste.

   Da fallback() während des "Leverage-Fensters" aufgerufen wurde, interagierte der Angriffskontrakt direkt mit dem Vertrag Vault, um eine WBTC-Short-Position (über increasePosition()) zu eröffnen, ohne globalShortAveragePrice zu aktualisieren, und erstellte anschließend einen WBTC-Short-Verringerungs-/Schließungsorder.

   

6. (Tx 6) Ein Keeper führte den WBTC-Short-Verringerungsorder (aus Schritt 5) über den Pfad Router-Ausführung aus. Die Ausführung erstellte auch einen WETH-Long-Verringerungsorder über den Fallback-Mechanismus im Vertrag PositionRouter.

   Da die WBTC-Short-Position ohne Aktualisierung von globalShortAveragePrice eröffnet wurde, führte die Schließung der Position bei gleichzeitiger Aktualisierung der Variable zu einem unerwarteten Rückgang von globalShortAveragePrice.

   

7. (Tx 7-14) Der Angreifer wiederholte die Schritte 5-6 viermal. Infolgedessen wurde globalShortAveragePrice von 1,08e35 auf 1,9e33 verzerrt.

   

Gewinnrealisierungsphase

8. (Tx 15) Ein Keeper führte den WETH-Long-Verringerungsorder (erstellt in Tx 14) über den Pfad Orderbook-Ausführung aus. Diese Ausführung löste die Gewinnrealisierungslogik im Angriffskontrakt aus, aufgrund der Reentrancy-Schwachstelle im Vertrag OrderBook.

   

   1. Bei dem Fallback-Aufruf lieh sich der Angriffskontrakt zunächst einen Flash-Loan von 7.538.567e18 USDC.

   2. Der Angriffskontrakt rief mintAndStakeGlp() auf, um 4.129.578e18 GLPs unter Verwendung von 6.000.000e18 USDC zu prägen.

   3. Der Angriffskontrakt rief Vault.increasePosition() auf, um eine WBTC-Short-Position mit den verbleibenden 1.538.567e18 USDC zu eröffnen. Da die globalen Short-Daten von WBTC extrem verzerrt waren, verstärkte die Auftragsausführung den AUM erheblich und erhöhte den GLP-Preis scharf.

   4. Der Angriffskontrakt rief unstakeAndRedeemGlp() auf, um GLPs zum erhöhten Preis gegen verschiedene Vermögenswerte im Vertrag Vault einzulösen.

   5. Der Angriffskontrakt rief Vault.decreasePosition() auf, um die WBTC-Short-Position zu schließen.

   6. Der Angriffskontrakt wiederholte die Schritte 8.b-8.e viermal, um alle Vermögenswerte im Vertrag Vault abzuzweigen.

   7. Der Angriffskontrakt beglich den Flash-Loan mit einem Gewinn von fast 42 Millionen US-Dollar.

Rückerstattung

Nach Verhandlungen mit dem Angreifer (Tx 16-18) akzeptierte der Angreifer schließlich ein 10%iges Kopfgeld und gab die verbleibenden gestohlenen Vermögenswerte zurück (Tx 19-21).

Zusammenfassung

Dieser Vorfall beinhaltete einen mehrphasigen Exploit gegen GMX V1 auf Arbitrum, der zu einem geschätzten Verlust von 42 Millionen US-Dollar führte. Der Angreifer nutzte eine Reentrancy-Schwachstelle im Vertrag OrderBook aus, um die Variable globalShortAveragePrice zu verzerren und den GLP-Preis aufzublähen. Durch die Nutzung des manipulierten Preises zog der Angreifer eine beträchtliche Menge an Vermögenswerten ab.

Schlüssel-Lektionen:

• Cross-Contract Reentrancy: Ein nonReentrant-Modifier auf einem einzelnen Vertrag verhindert keine Reentrancy in andere Verträge innerhalb desselben Systems. Zugriffssteuerungsmechanismen, die auf einer temporären Markierung (z. B. dem "Leverage-Fenster") basieren, können umgangen werden, wenn ein externer Aufruf erfolgt, bevor die Markierung zurückgesetzt wird.
• Betriebssicherheit: Dieser Angreifer nutzte das Protokoll in drei verschiedenen Phasen aus und führte insgesamt 15 Transaktionen durch. Dieser Vorfall unterstreicht die kritische Notwendigkeit von Echtzeitüberwachung, sofortigen Alarmen und effektiven Abwehrstrategien.

Referenzen

1. https://x.com/GMX_IO/status/1942955807756165574
2. https://x.com/GMX_IO/status/1943336664102756471
3. GMX V1

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden bei der Code-Auditierung (einschließlich Smart Contracts, Blockchain und Wallets), der Echtzeit-Abwehr von Angriffen, der Analyse von Vorfällen, der Rückverfolgung illegaler Gelder und der Erfüllung von AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg unterstützen.

BlockSec hat mehrere Arbeiten zur Blockchain-Sicherheit auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen US-Dollar zu retten, und Kryptowährungen im Wert von mehreren Milliarden gesichert.

• Offizielle Website: https://blocksec.com/

• Offizieller Twitter-Account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Audit-Dienstleistung : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance