Proč se říká, že Hook je "dvojsečný meč" Uniswap V4?

Věřím, že Uniswap v4 bude brzy k dispozici všem!
Tentokrát má tým Uniswap ambiciózní cíle a plánuje zavést mnoho nových funkcí [1], včetně podpory neomezeného počtu fondů likvidity a dynamických poplatků za obchodní pár, singleton designu, bleskového účtování, Hooks a podpory standardu tokenů ERC1155. . S využitím přechodného úložiště zavedeného EIP-1153 se očekává vydání Uniswap v4 po upgradu Ethereum Cancun.
Mezi mnoha inovacemi, mechanismus Hook přitáhl širokou pozornost díky svému silnému potenciálu. Mechanismus Hook podporuje spouštění specifického kódu v určitých bodech životního cyklu fondu likvidity, což výrazně zvyšuje škálovatelnost a flexibilitu fondu.
Hákovým mechanismem však může být i dvousečná zbraň. Přestože je výkonný a flexibilní, jeho bezpečné používání je také velkou výzvou. Složitost háčků nevyhnutelně přináší nové potenciální útočné vektory. Proto doufáme, že napíšeme sérii článků, které systematicky představí bezpečnostní problémy a potenciální rizika související s mechanismem Hook, abychom podpořili vývoj zabezpečení komunity. Věříme, že tyto poznatky pomohou vybudovat bezpečný Uniswap v4 Hook.
Jako začátek této série článků tento článek představuje koncepty související s mechanismem Hook v Uniswap v4 a nastiňuje bezpečnostní rizika mechanismu Hook.
Mechanismus Uniswap V4
Než se do toho pustíme, musíme mít základní znalosti o mechanismu Uniswap v4. Podle oficiálního oznámení [1] a bílé knihy [2] jsou háky, singletonová architektura a bleskové účtování tři důležité funkce pro implementaci vlastních fondů likvidity a dosažení efektivního směrování napříč více fondy.
1.1 Háček
Háky označují smlouvy, které běží v různých fázích životního cyklu fondu likvidity. Tým Uniswap doufá, že zavedením Hooků umožní komukoli dělat kompromisní rozhodnutí. Tímto způsobem je možné nativně podporovat dynamické poplatky, přidávat on-chain price cap objednávky nebo rozkládat velké objednávky prostřednictvím časově váženého průměrného tvůrce trhu (TWAMM).
V současné době existuje osm zpětných volání Hook, rozdělených do čtyř skupin (každá skupina obsahuje pár zpětných volání):
beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
předSwap/afterSwap
předDonate/poDonate
Následuje proces výměny háčků představený v bílé knize [2].
Obrázek 1: Proces Exchange Hook
Tým Uniswap představil, jak to udělat, pomocí několika příkladů (jako je TWAMM Hook[3]) a účastníci komunity také poskytli určité příspěvky. Oficiální dokumentace[4] také odkazuje na úložiště Awesome Uniswap v4 Hooks[5], které shromažďuje další příklady Hook.
1.2 Singleton, účtování blesků a uzamykací mechanismus
Architektura Singleton a flash účetnictví jsou navrženy tak, aby zlepšily výkon snížením nákladů a zajištěním efektivity. Zavádí nový singleton kontrakt, kde jsou všechny fondy likvidity drženy ve stejném smart kontraktu. Tento singleton design spoléhá na PoolManager pro ukládání a správu stavu všech fondů.
V dřívějších verzích protokolu Uniswap zahrnovaly operace, jako je výměna nebo přidávání likvidity, přímé převody tokenů. Verze v4 se liší v tom, že zavádí bleskové účtování a mechanismus zámku.
Uzamykací mechanismus funguje následovně:
1. Smlouva o skříňce vyžaduje zámek na PoolManager.
2. PoolManager přidá adresu smlouvy o skříňce do fronty lockData a zavolá zpětné volání lockAcquired.
3. Smlouva o skříňce vykonává svou logiku ve zpětném volání. Během provádění může interakce smlouvy o skříňce s fondem vést k nenulovým přírůstkům měny. Na konci provádění se však všechny delty musí vyrovnat na nulu. Kromě toho, pokud fronta lockData není prázdná, může operace provádět pouze poslední smlouva skříňky.
4. PoolManager kontroluje stav fronty lockData a přírůstek měny. Po ověření PoolManager smaže smlouvu o skříňce.
Stručně řečeno, zamykací mechanismus zabraňuje souběžnému přístupu a zajišťuje, že všechny transakce mohou být vymazány. Smlouva o skříňce platí pro zámky v pořadí a poté provádí transakce prostřednictvím zpětného volání lockAcquired. Odpovídající zpětné volání Hook bude spuštěno před a po každé operaci fondu. Nakonec PoolManager zkontroluje stav.
Tento přístup znamená, že operace spíše než provádění okamžitého převodu upravuje vnitřní čistý zůstatek (tj. delta). Jakékoli změny budou zaznamenány do vnitřního zůstatku fondu a skutečný převod bude proveden na konci operace (tj. uzamčení). Tento proces zajišťuje, že neexistují žádné zbývající tokeny, čímž je zachována integrita prostředků.
Kvůli zamykacímu mechanismu nemohou účty externího vlastnictví (EOA) komunikovat přímo s PoolManager. Místo toho musí k jakékoli interakci dojít prostřednictvím smlouvy. Tato smlouva funguje jako přechodná skříňka a před provedením jakýchkoli operací fondu musí požádat o uzamčení.
Existují dva hlavní scénáře interakce smlouvy:
Určitá smlouva o skříňce pochází z oficiální kódové základny nebo je nasazena uživateli. V tomto případě si můžeme interakci představit jako průchod přes router.
Smlouva o skříňce a Hook jsou integrovány do stejné smlouvy nebo jsou kontrolovány subjektem třetí strany. V tomto případě můžeme interakci považovat za probíhající prostřednictvím Hooks. V tomto případě hraje Hook jak roli smlouvy se skříňkou, tak je zodpovědný za zpracování zpětných volání.
Model ohrožení
Než budeme diskutovat o souvisejících bezpečnostních problémech, musíme identifikovat model hrozby. Uvažujeme především o následujících dvou situacích:
Model hrozby I: Samotné háčky jsou neškodné, ale mají zranitelnost.
Model hrozby II: Háčky jsou ze své podstaty škodlivé.
V následujících částech diskutujeme o potenciálních bezpečnostních problémech na základě těchto dvou modelů hrozeb.
2.1 Bezpečnostní problémy v modelu hrozeb I
Threat Model I se zaměřuje na zranitelnosti související se samotným Hookem. Tento model hrozby předpokládá, že vývojáři a jejich háky jsou neškodní. V Hooks se však mohou objevit i existující známé zranitelnosti v chytrých kontraktech. Pokud je například Hook implementován jako upgradovatelná smlouva, může narazit na problémy podobné zranitelnosti UUPSUupgradeable OpenZeppelin.
S ohledem na výše uvedené faktory jsme se rozhodli zaměřit se na potenciální zranitelnosti jedinečné pro verzi v4. V Uniswap v4 jsou Hooks chytré smlouvy schopné provádět vlastní logiku před nebo po operacích základního fondu, včetně inicializace, úpravy pozice, výměny a shromažďování. I když se očekává, že Hooks implementují standardní rozhraní, umožňují také zahrnutí vlastní logiky. Proto se naše diskuse omezí na logiku zahrnující standardní rozhraní Hook. Poté se pokusíme identifikovat možné zdroje zranitelnosti, například jak by Hooks mohl zneužívat tyto standardní Hook funkce.
Konkrétně se zaměříme na následující dva typy háčků:
Prvním háčkem je udržení uživatelských prostředků. V tomto případě může útočník zaútočit na tento háček, aby převedl finanční prostředky a způsobil ztrátu majetku.
Druhý typ háku ukládá klíčová stavová data, na která uživatelé nebo jiné protokoly spoléhají. V takovém případě se útočník může pokusit kritický stav změnit. Potenciální rizika mohou nastat, když nesprávný stav použijí jiní uživatelé nebo protokoly.
Vezměte prosím na vědomí, že háčky mimo tyto dva rozsahy jsou mimo rozsah naší diskuse.
Protože v době psaní tohoto článku neexistují žádné skutečné případy použití pro Hooks, stáhneme některé informace z úložiště Awesome Uniswap v4 Hooks.
Po hlubokém ponoru do úložiště Awesome Uniswap v4 Hooks (commit hash 3a0a444922f26605ec27a41929f3ced924af6075) jsme objevili několik kritických zranitelností. Tyto zranitelnosti pocházejí hlavně z riskantních interakcí mezi hooky, PoolManagerem a externími třetími stranami a lze je rozdělit hlavně do dvou kategorií: problémy s řízením přístupu a problémy s ověřováním vstupů. Konkrétní zjištění naleznete v následující tabulce:
Celkem jsme našli 22 relevantních projektů (kromě projektů nesouvisejících s Uniswap v4). Z těchto projektů se domníváme, že 8 (36 %) projektů je zranitelných. Z osmi zranitelných projektů mělo šest problémy s řízením přístupu a dva byly zranitelné vůči nedůvěryhodným externím voláním.
2.1.1 Problémy s řízením přístupu
V této části diskuse se zaměřujeme především na problémy, které mohou být způsobeny funkcemi zpětného volání ve verzi 4, včetně zpětných volání s 8 zavěšením a zpětných volání zámku. Samozřejmě existují další situace, které je třeba ověřit, ale tyto situace se liší podle návrhu a jsou nad rámec naší diskuse.
Tyto funkce by měl volat pouze PoolManager a nelze je volat z jiných adres (včetně EOA a smluv). Například v případě, kdy jsou odměny distribuovány pomocí klíčů fondu, mohou být odměny nárokovány nesprávně, pokud lze příslušnou funkci volat z jakéhokoli účtu.
Proto je zásadní vytvořit silné mechanismy řízení přístupu pro háky, zejména proto, že je mohou volat jiné strany kromě samotného fondu. Přísnou správou přístupových práv mohou fondy likvidity výrazně snížit riziko neoprávněných nebo škodlivých interakcí s háčky.
2.1.2 Problémy s ověřením vstupu
V Uniswap v4, kvůli mechanismu zámku, musí uživatelé získat zámek prostřednictvím smlouvy před provedením jakýchkoli operací fondu fondů. To zajišťuje, že smlouva, která se aktuálně účastní interakce, je nejnovější smlouvou o skříňce.
Přesto existuje možný scénář útoku, konkrétně nedůvěryhodná externí volání kvůli nesprávnému ověření vstupu v některých zranitelných implementacích Hook:
Za prvé, hák neověřuje fond finančních prostředků, se kterými má uživatel v úmyslu pracovat. Může se jednat o škodlivý fond obsahující falešné tokeny a spouštějící škodlivou logiku.
Za druhé, některé funkce zavěšení klíčů umožňují libovolné externí hovory.
Nedůvěryhodné externí hovory jsou extrémně nebezpečné, protože mohou vést k různým typům útoků, včetně toho, co známe jako reentrancy útoky.
Za účelem útoku na tyto zranitelné háčky může útočník zaregistrovat škodlivý fond fondů pro své vlastní falešné tokeny a poté zavolat hák, aby provedl operace v fondu fondů. Při interakci s fondem logika škodlivého tokenu unese řídicí tok, aby se zapojila do nežádoucího chování.
2.1.3 Preventivní opatření proti modelu ohrožení I
Aby se předešlo takovým bezpečnostním problémům souvisejícím s háky, je zásadní ověřovat interakce řádným vynucováním nezbytných kontrol přístupu k citlivým externím/veřejným funkcím a ověřováním vstupních parametrů. Kromě toho může ochrana proti opětovnému vstupu pomoci zajistit, aby se hák neprováděl opakovaně ve standardním logickém toku. Zavedením vhodných bezpečnostních opatření mohou fondy snížit rizika spojená s takovými hrozbami.
2.2 Bezpečnostní problémy v modelu hrozeb II
V tomto modelu hrozeb předpokládáme, že vývojář a jeho háček jsou škodlivé. Vzhledem k širokému záběru se zaměřujeme pouze na bezpečnostní otázky související s verzí v4. Klíčem tedy je, zda poskytnutý hák dokáže zpracovat kryptoaktivy přenesené nebo autorizované uživatelem.
Protože způsob přístupu k háku určuje oprávnění, která mohou být háku udělena, rozdělujeme háček do dvou kategorií:
Spravované háky: Háčky nejsou vstupní body. Uživatelé musí komunikovat s hákem prostřednictvím routeru (možná poskytovaného Uniswapem).
Samostatné háčky: Háčky jsou vstupní body, které uživatelům umožňují přímou interakci s nimi.
Obrázek 2: Příklad škodlivého Hooka
2.2.1 Spravovaný hák
V tomto případě jsou šifrovací prostředky uživatele (včetně nativních tokenů a dalších tokenů) přeneseny nebo autorizovány do routeru. Vzhledem k tomu, že PoolManager provádí kontroly zůstatku, není pro škodlivé háky snadné tyto prostředky přímo ukrást. Stále však existuje potenciální útočná plocha. Například mechanismus správy výdajů verze v4 může být manipulován útočníky prostřednictvím háčků.
2.2.2 Nezávislý hák
Situace je ještě složitější, když se jako vstupní body používají háky. V tomto případě získá hák větší sílu, protože s ním může uživatel přímo komunikovat. Teoreticky si hák může s touto interakcí dělat, co chce.
Ve verzi v4 je ověření logiky kódu velmi důležité. Hlavním problémem je, zda lze manipulovat s logikou kódu. Pokud je háček upgradovatelný, znamená to, že zdánlivě bezpečný háček se po upgradu může stát škodlivým, což představuje značné riziko. Mezi tato rizika patří:
Upgradovatelní agenti (lze na ně přímo zaútočit);
Se sebedestruktivní logikou. Může být napaden, když jsou společně volány selfdestruct a create2.
2.2.3 Preventivní opatření proti modelu ohrožení II
Je důležité vyhodnotit, zda je háček škodlivý. Konkrétně u řízených háčků bychom se měli zaměřit na chování správy poplatků, zatímco u samostatných háčků je hlavní důraz kladen na to, zda jsou upgradovatelné.
na závěr
V tomto článku nejprve poskytujeme stručný přehled základních mechanismů souvisejících s bezpečnostními problémy Uniswap v4’s Hook. Následně navrhujeme dva modely hrozeb a stručně nastíníme související bezpečnostní rizika.
V následujících článcích provedeme hloubkovou analýzu bezpečnostních problémů v rámci každého modelu hrozeb.